Microsoft single sign-on, explained
What Microsoft (Entra ID) single sign-on is, who it applies to, how it fits alongside the other sign-in methods, what employees see, and how the sign-in protects your people.
Single sign-on (SSO) lets your employees sign in to CLVR Benefits with the Microsoft work account they already use for email and Microsoft 365, instead of a sign-in link, a one-time code, or a password. It is optional, set up once per company, and tied to a single email domain. This article explains what SSO is, who it applies to, how it sits alongside the other sign-in methods, exactly what employees see, and how the sign-in protects your people and your company.
What employees see with SSO
When SSO is active for your domain, an employee enters their work email on the sign-in page and CLVR shows a short Microsoft sign-in notice and a single Continue with Microsoft button. No sign-in link, code, or password fields appear. They continue with their Microsoft work account and land in CLVR Benefits.
Because the account lives in Microsoft, CLVR Benefits never sees or stores your employees' Microsoft passwords. Sign-in happens on Microsoft's own screens, and your company's existing rules (multi-factor authentication, conditional access) apply automatically.
Who it applies to
SSO is set up per company and tied to one email domain, for example company.com. It applies to the employees whose work email is on that domain:
- An employee on the SSO domain signs in with Continue with Microsoft.
- An employee whose email is on a different domain does not see the Microsoft option; they keep whichever method applies to their address.
SSO is matched on the email domain, not on a list of names. Anyone you add to CLVR Benefits with an email on the configured domain automatically gets Microsoft sign-in, with nothing extra to switch on per person.
How SSO relates to the other sign-in methods
Employees never pick a method themselves. The sign-in screen reads the work email each person enters and offers the first method that matches, highest priority first, in this order:
- Microsoft single sign-on. If the email is on the domain you configured for Microsoft sign-in, the person sees the Microsoft sign-in notice and a single Continue with Microsoft button, and no other options.
- Email and password. If the domain is set up for password sign-in (a list CLVR maintains for companies whose email security blocks links), the person enters a password after their email.
- A sign-in link. Everyone else gets a one-time sign-in link emailed to them by selecting Send sign-in link. The same email also carries a one-time code they can enter instead.
Microsoft sign-in always wins where it applies, so it overrides password and sign-in link for employees on the configured domain.
What happens to the other options when SSO is on
When SSO is active for a domain, it takes over completely for employees on that domain. For them, the sign-in screen shows only the Microsoft sign-in notice and the Continue with Microsoft button. The sign-in link, the one-time code, and the password options are all hidden, so there is one clear way in.
This only affects employees whose email is on your configured Microsoft domain. Anyone on a different domain falls back to the next method that applies to them:
- A sign-in link by default. They select Send sign-in link and open the link from the email, or enter the one-time code from the same email.
- Email and password, only if their domain is set up for password sign-in.
So enabling Microsoft sign-in for your main domain leaves everyone else exactly where they were before.
Turning SSO on does not change how anyone outside your Microsoft domain signs in. A contractor or a colleague on a different address still uses Send sign-in link (or your password option), and their benefits work exactly the same.
The welcome email matches the same order
When a new employee is added, CLVR sends a Welcome to CLVR Benefits email with sign-in instructions. Those instructions follow the same priority as the sign-in screen, so a new employee on your Microsoft domain is told to sign in with their Microsoft work account, while everyone else is pointed to the sign-in link (or password, if set up). You do not need to write separate instructions: the welcome email already reflects whichever method applies to each person.
If SSO is later removed or changes
SSO is a per-company setting your CLVR contact manages, not something you switch on or off from the webapp. If it is ever removed or its configuration changes, employees on that domain simply fall back to the next method that applies to them, usually the sign-in link. Nobody is locked out: their CLVR account and benefits are unchanged, only the way they sign in moves down to the next available option.
The sign-in experience step by step
Once Microsoft SSO is live for your domain, here is exactly what an employee on that domain sees, so you know what to tell your team:
The employee opens the CLVR Benefits sign-in page and enters their work email in the Sign in with Email field. CLVR checks the email domain as they type, and again when they continue, so the right option appears.
Because their domain has SSO enabled, an info notice titled Microsoft sign-in appears: "Your company uses Microsoft sign-in. Click the button below to sign in with your work account." A Continue with Microsoft button shows below it.
The employee selects Continue with Microsoft. CLVR sends them to Microsoft to sign in with their work account, then returns them to CLVR Benefits, signed in.
What to tell employees
- Sign in with your work email and select Continue with Microsoft.
- You are taken to your familiar Microsoft sign-in, the same one you use for email and other work tools.
- There is nothing extra to set up, and no separate CLVR password to remember.
How SSO sign-in works and what it does for security
Behind the Continue with Microsoft button is the standard Microsoft OAuth flow:
The employee selects Continue with Microsoft and is redirected to Microsoft to sign in with their work account.
Microsoft authenticates them (and applies any multi-factor checks your company already requires) and returns them to CLVR Benefits with a one-time authorization code.
CLVR Benefits exchanges that code with Microsoft for an access token, then reads only the employee's email and name from Microsoft Graph (the User.Read permission).
CLVR matches that email to an active employee in your company and creates the CLVR session. The employee lands on their dashboard.
What CLVR reads and stores
- What CLVR reads from Microsoft: the employee's email address and display name, through the User.Read permission. That is all the flow asks for.
- What CLVR never sees: the employee's Microsoft password. Authentication stays entirely with Microsoft, so CLVR Benefits never receives, handles, or stores it.
- What CLVR stores for your company: the Microsoft connection details (domain, tenant ID, client ID, and client secret) that IT enters during setup. These are kept securely and used only to enable Microsoft sign-in for your domain.
The session lasts up to 24 hours. After that the employee signs in with Microsoft again. They are not asked to re-enter anything inside CLVR in between.
Who is allowed in
Sign-in succeeds only when all of these are true, so the right people get in and no one else does:
- The Microsoft account's email is on the domain your company configured for SSO.
- The email matches an active employee in your company in CLVR.
- The employee has not been marked as terminated.
If any check fails, sign-in is blocked and the employee sees a clear message rather than being let in. An account on a different domain, or one that has left the company, cannot sign in.
Privacy and security
- Passwords stay with Microsoft, never with CLVR.
- Only the email and name needed to identify the employee are read, nothing more.
- The stored Microsoft credentials are kept securely and used solely to enable sign-in.
- CLVR Benefits is GDPR compliant. For the full picture, see our Privacy Policy and Trust Center.
SSO is optional
You do not have to use SSO. Companies without it keep signing in with a sign-in link by default, or with email and password on domains set up for that. SSO is worth requesting if your team already lives in Microsoft 365 and you want one fewer set of credentials to manage.
Turning SSO on is a one-time setup. Your HR team starts it with your CLVR contact, who sends a secure, time-limited setup link to your IT or Microsoft 365 contact. Your IT contact registers an application in Microsoft and enters the technical details on that setup page. Your HR team coordinates the request but does not handle the credentials. Once the setup is saved, employees on the domain can sign in with Microsoft straight away. To start the process, see how to request SSO for your company.
Troubleshooting
- An employee on our domain still sees the sign-in link, not the Microsoft button. SSO may not be live yet, or they may be entering a different email. Check that the email is on your configured Microsoft domain, then see "Confirming SSO is live" and "SSO not showing on the sign-in screen".
- Someone on a different domain cannot use Microsoft. That is expected. They should use Send sign-in link and open the link from their email, or enter the one-time code from the same email.
- Sign-in links never arrive for a group of employees. Their email security may be holding links back. Ask your CLVR contact whether that domain should move to email and password instead.
- You want to confirm SSO is actually live. Sign-in screen behaviour is the quickest check: a work email on your domain should show only the Microsoft sign-in notice and Continue with Microsoft. See "Confirming SSO is live" for the full checklist.