How Single Sign-On works for Moves+, what we need from your IT team, and how a rollout runs from first conversation to go-live.
Time required: 30 minutes to read; 1 to 2 weeks for a typical rollout
User role: IT administrator, project lead
Module: Moves+
Overview
With SSO enabled, your members sign in to the Moves+ app with the account they already use for everything else at your organisation. They do not create or remember a separate Moves+ password, and you keep control of who has access.
Authentication happens through your own identity provider using SAML 2.0. Moves+ never sees or stores your members' passwords; your identity provider confirms who the person is, and Moves+ trusts that confirmation.
SSO covers both the Moves+ app for members and the Moves+ admin dashboard for your staff.
⚠️ Moves+ is either SSO or email sign-in, not both. Once SSO is enabled for your organisation, email and password sign-in is switched off for all of your members. There is no option to run the two side by side, so plan your communications on that basis.
What SSO does
✅ Members sign in with their existing organisation credentials.
✅ Access follows your identity provider, so removing someone there removes their access to Moves+.
✅ Your IT team keeps control of password policy, multi-factor authentication and conditional access.
✅ No Moves+ password to reset, which removes the most common support request we see.
What SSO does not do
❌ It does not sync your directory. Member records are created when someone first signs in, not pushed to us in advance. There is no SCIM or directory sync integration.
❌ It does not keep profile details up to date automatically after that first sign-in.
❌ It does not run alongside email sign-in. Enabling SSO replaces it.
Before you start
| Prerequisite | Details |
|---|---|
| ✅ SAML 2.0 identity provider | Your organisation's IdP must support SAML 2.0 with signed assertions |
| ✅ A named admin contact | One person with authority to change DNS records and configure the IdP. They receive the setup invitation from us |
| ✅ Your email domain or domains | Every domain your members sign in with, for example organisation.com. Members whose email domain is not registered cannot sign in |
| ✅ A decision on which email address your IdP sends | See Email addresses and aliases below. This is the most common cause of problems, so settle it before you configure anything |
| ✅ Ability to add a DNS TXT record | Needed once, to verify you own the domain |
| ✅ Two test accounts | One ordinary member and one member of staff, so both routes can be checked before go-live |
| ✅ Agreement with your Client Success Manager | SSO is enabled per client by OpenPlay and is a chargeable addition. Your CSM will confirm the commercial detail |
Email addresses and aliases
Read this section before you configure anything. It is the difference between a clean go-live and a set of duplicate accounts.
When SSO is switched on, we match each person to their existing Moves+ account on their email address, matched exactly. Capitalisation does not matter, but everything else does.
Many organisations issue two addresses for the same person:
- A primary address based on a student or staff number, for example
s1234567@organisation.com - A friendlier alias based on their name, for example
a.person@organisation.com
Members typically know and use the name-based alias, while the identity provider often sends the number-based primary. When those two differ, the person arrives as a brand new member with no points, badges or history, and ends up with two accounts.
To avoid it:
- Decide which address your identity provider will send, and confirm it with us before go-live.
- Check that address against the addresses already in Moves+. If your members registered with the alias but your IdP sends the primary, tell us before you enable SSO so we can plan the mapping.
- Tell your members which address to expect, so they are not surprised.
- Keep it consistent. Changing which address the IdP sends after go-live will create duplicates.
If you are not sure which address your members used to register, ask your Client Success Manager for a list before you configure the connection.
Who does what
SSO for Moves+ is a shared job. Your team owns the parts that touch your organisation's identity; OpenPlay owns the configuration inside Moves+.
| Step | Owner |
|---|---|
| 1. Confirm the domains, IdP, named admin contact and which email address will be sent | You |
| 2. Create your organisation and send the setup invitation | OpenPlay |
| 3. Verify your domain with a DNS record | You |
| 4. Configure your identity provider and attribute mapping | You |
| 5. Configure the Moves+ side and set your domain match | OpenPlay |
| 6. Test with a member account and a staff account | You and OpenPlay together |
| 7. Enable SSO for live members | OpenPlay, on your go-ahead |
⚠️ Steps 3 and 4 must be finished before step 7. If SSO is switched on before your identity provider is configured, nobody at your organisation can sign in. We deliberately keep step 7 as the last action, on your explicit go-ahead.
Steps
1. Send us your details
Tell your Client Success Manager:
- The full name of your organisation as members should see it in the app
- Every email domain your members will sign in with
- Which email address your identity provider will send, primary or alias
- The name and email address of the person who will configure the identity provider
- Which identity provider you use
2. Accept the setup invitation
Your named contact receives an emailed invitation to a secure setup portal. This portal is provided by our authentication partner and is branded accordingly, so it will not carry OpenPlay branding; the link is genuine and comes from us.
Opening it presents two tasks, which can be done in either order:
- Verify your domain
- Configure Single Sign-On
3. Verify your domain
- Enter the domain your members sign in with, for example
organisation.com - Add the DNS TXT record shown, to that domain
- Return to the portal and confirm verification
Verification can take up to an hour to propagate, and occasionally longer depending on your DNS provider's cache settings. Repeat this for each additional domain.
4. Configure Single Sign-On
- Select your identity provider from the list
- Follow the guided steps for that provider; they differ by provider, and the portal shows the exact values to copy
- Complete the attribute mapping described below
- Save and confirm the connection shows as active
5. Configure attribute mapping
Your identity provider must send the following with each sign-in. A missing required attribute causes the sign-in to fail rather than partially succeed, so it is worth checking each one.
| Attribute | Required | Description | Notes |
|---|---|---|---|
| Email address | Yes | The member's email address | Must be on a domain you have verified. Used to match the person to their existing Moves+ record, so see Email addresses and aliases above |
| First name | Yes | The member's first name | Sign-in fails if this is empty |
| Last name | Yes | The member's last name | Sign-in fails if this is empty |
| Role | Only for staff | Marks someone as Staff | Leave unset for ordinary members. Everyone without it becomes a Member, which is the default |
Roles. There are two:
- Member is the default. Anyone signing in without a role assigned becomes a Member and gets the app.
- Staff must be assigned explicitly in your identity provider. Staff get the Moves+ admin dashboard as well as the app.
You therefore only need to configure the role attribute for the people who administer Moves+ for your organisation. Ordinary members need nothing.
6. Test before go-live
We will enable SSO for testing and check, with you:
- A member signs in successfully and lands in the app
- A member of staff signs in successfully and can reach the admin dashboard
- An existing member is matched to their existing account, with their points and history intact
- A member whose email is on an unverified domain is correctly refused
- The attributes arriving from your identity provider are complete and correct
Step 3 is the one worth spending time on. Test it with a real member who already has points and history, not a fresh test account.
7. Go live
On your go-ahead, we enable SSO for all members. From that point, members on your verified domains sign in through your identity provider, and email sign-in is no longer available.
What your members will see
In the Moves+ app, members select your organisation from the list, tap "Sign in with SSO", then sign in with their organisation account. Your own sign-in page opens, they authenticate there including any multi-factor step you require, and they return to the app signed in.
There is a separate article you can share with them: Signing in to Moves+ with your organisation account.
Troubleshooting
An existing member has signed in but their points and history have gone.
Their identity provider address does not match the address on their Moves+ account, usually because of a primary address and alias mismatch. Contact your Client Success Manager; do not ask them to create a new account.
A member sees our sign-in page but is refused by Moves+ afterwards.
The attributes arriving from your identity provider are incomplete. Check that email address, first name and last name are all being sent and are not empty.
A member on a different domain cannot sign in.
Only verified domains can be used. Send your Client Success Manager the additional domain and we will add and verify it.
Domain verification is not completing.
Confirm the TXT record is on the exact domain shown, with no typographical errors, and allow up to an hour for propagation. Some DNS providers append the domain automatically, which can produce a doubled record.
A member of staff can sign in to the app but not the admin dashboard.
The Staff role is not assigned to them in your identity provider. Members without a role become ordinary Members by default.
Can we let some members use email sign-in and others use SSO?
No. Moves+ is one or the other for the whole organisation.
We need to turn SSO off.
Contact your Client Success Manager. We can disable it, and members return to signing in with email as they did previously.
Security and data
Authentication uses SAML 2.0 with signed assertions. Moves+ does not receive, store or process your members' passwords at any point; your identity provider authenticates the person and returns a signed assertion confirming their identity and the attributes above.
We use a specialist authentication provider to broker the SAML connection between Moves+ and your identity provider. If your information security or procurement team needs the provider named, along with their compliance certifications and the data processed, your Client Success Manager will supply it.
Authentication events are logged so that our technical team can support you.