My single sign-on login fails
Get back in with an Owner's password first, then check the test result, the domain, the certificate and the values your identity provider holds.
This page is for the people who set up single sign-on: the Owners of the account that holds the workspace. Single sign-on works with SAML 2.0 and OpenID Connect identity providers and is available on the Enterprise plan. See Set up single sign-on.
First, get back in
The Owners of the account can always sign in with their password or passkey, even while single sign-on is required, so a broken identity provider cannot lock the workspace out. Sign in that way, open Single sign-on & SCIM in the workspace settings, and work through the checks below.
Run Test connection
Under 3. Test the connection, select Test connection. It runs a real sign-in and, when it fails, shows Last test failed: with the reason. That is usually faster than reading your identity provider's logs.
Check the domain
Single sign-on applies to email addresses on the domain you verified with a TXT record. If the record has been removed from your DNS, publish it again and select Verify domain. Requiring single sign-on cannot be turned back on until the domain is verified and a connection test passes.
Check the certificate or the client secret
Sign-ins that worked for months and then started failing for everyone at once usually mean a credential changed on the identity provider's side:
- SAML: the provider rotated its signing certificate. transglot checks the signature on every sign-in, so paste the new one into Signing certificate and save.
- OpenID Connect: the client secret was rotated or expired. Paste the new Client secret into the connection and save.
Check the values on both sides
Your identity provider needs the values shown under Values for your identity provider. Copy them from that card rather than typing them: a redirect address or audience that differs by one character fails at sign-in, with an error from your provider rather than from transglot. In the other direction, the provider's own values in the connection (the IdP entity ID and SSO URL for SAML, or the Issuer URL and Client ID for OpenID Connect) must match what the provider publishes, character for character, including any trailing slash.
Check the person
- Are they assigned to the app in your identity provider? A provider can sign someone in and still refuse to send transglot an assertion for an app they are not assigned to.
- Is their email address the same on both sides? The email address your provider sends is what matches a person in transglot. If your directory holds one address and transglot another, the sign-in succeeds at the provider and fails here.
Related
I can't sign in
Work through these in order: the cause is usually the password, the second factor, or single sign-on on your company's domain.
My import did not bring everything across
Usually the run is still going or stopped early, the token could not see everything, or the content is something an import does not carry.