Single sign-on fails
The page in Account settings › Users & Security › Single Sign-on has three steps: Identity provider, Connect, and Check and enable. Problems fall into two groups: the setup does not complete, or sign-in fails for people. Find yours.
I am locked out because sign-in is Required
Section titled “I am locked out because sign-in is Required”Check. In Check and enable, the mode Required turns password sign-in off for everyone except workspace owners. Test single sign-on with a user account before selecting Required.
Fix. A workspace owner signs in with a password and switches the mode to Optional. With Optional, single sign-on is offered first, and passwords still work. Test with Optional before you ever choose Required.
The page will not discover endpoints
Section titled “The page will not discover endpoints”Check. The page needs the right start value: the Directory (tenant) ID for Microsoft Entra ID, the Okta domain for Okta, and the Discovery URL for Google Workspace or Other OpenID. Without it, you see Enter the Directory (tenant) ID first., Enter your Okta domain first. or Enter the discovery URL first.
Fix. Enter the value, then discover. The page reports Endpoints discovered. when the provider answers. If you change the discovery address later, the endpoints are cleared, because they would be out of date. Run discovery again.
Run checks reports a problem
Section titled “Run checks reports a problem”Check. Run checks confirms that the provider answers. Test sign-in with a user account too.
Fix. Fix what the check names. Then test with a real account, which is the only end-to-end proof: open the app’s sign-in page in a private window and sign in as a person, not as the admin.
The provider rejects the sign-in
Section titled “The provider rejects the sign-in”Check. The provider shows its own error before it sends the person back. The usual cause is the Redirect URI. The page shows the exact address to register. It is built from your workspace address, and it changes if you move to a custom domain.
Fix. In your provider, create the app registration as type Web, and add the Redirect URI exactly as the page shows, with no changes. Paste the Client ID. For the secret, copy the secret Value, not the Secret ID. The value is shown once. After saving, the page shows only Saved · ending ···· and the last characters. Use Replace to enter a new one.
The person is not offered single sign-on
Section titled “The person is not offered single sign-on”Check. Sign-in asks for the email first, and then decides. If the email is not a user of the workspace, the page says We could not continue with that email. Please check it and try again. If the person is a user and single sign-on is Enabled, they are sent to the provider. Otherwise they see the password box. The email step is valid for 10 minutes. After that, the page says Your sign-in request expired. Please start again.
Fix. Check the status chip at the top of the page: Not set up, Incomplete, Ready to enable or Enabled. Turn on Turn on single sign-on. Check the person’s email in Users, and ask them to start again from the first screen.
The provider signs in a different email
Section titled “The provider signs in a different email”Check. After the provider confirms the person, Beezr compares the email in the provider’s answer with the email the person typed on the Beezr sign-in page. The comparison ignores capitals. If they differ, the person lands on Authentication Failed. This happens when someone types a personal address, or when the provider returns a different alias or preferred_username.
Fix. Ask the person to type the same work email that their provider account uses. If the provider returns an alias, make the Beezr user’s email match it.
The Authentication Failed page appears
Section titled “The Authentication Failed page appears”Check. Your administrator can read the reason in the server’s output. These are the checks Beezr makes when the person returns from the provider, and the messages the log carries:
| Message in the log | What it means |
|---|---|
Invalid OIDC callback state. | The sign-in took too long, was opened in another tab, or the page was refreshed. The code can be used once |
OIDC token exchange failed. | The provider refused the code. Check the Client ID, the secret and the Redirect URI |
OIDC nonce does not match. | The sign-in did not start from your sign-in page, or the session expired |
Invalid audience | The token was issued for a different client than the one saved |
Invalid issuer | The Issuer on the page does not match the provider’s. Run discovery again |
ID token expired | The token arrived too late, or the server clock is wrong |
No email claim found in ID token | The provider did not send an email or preferred_username value |
Fix. Start over from the sign-in page, and do not refresh or go back during the redirect. For a missing email, add the email claim to the provider’s app registration. For issuer and audience problems, run discovery again and check the Client ID.
Sign-in is blocked after the provider succeeds
Section titled “Sign-in is blocked after the provider succeeds”Check. Single sign-on applies your location policies. After the provider confirms the person, Beezr loads the Geo fencing policies that apply to them. A policy that denies the location shows a Location restriction message.
Fix. Try again. If it repeats, check the Geo fencing policies that target the person or their role, and ask your administrator to read the server log.