Skip to content

Single sign-on fails

Troubleshooting7 minExpert

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.

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.

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.

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.

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.

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.

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 logWhat 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 audienceThe token was issued for a different client than the one saved
Invalid issuerThe Issuer on the page does not match the provider’s. Run discovery again
ID token expiredThe token arrived too late, or the server clock is wrong
No email claim found in ID tokenThe 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.