Testing and troubleshooting - Enterprise SSO
Testing the integration
Save the configuration and sign in with a company account that has a counterpart in DockRay with the same confirmed e-mail address. Check that after returning from the provider you land in the panel logged in, and - if the account has the second factor on - that the panel asked for it. Sign out and back in again: the second login should behave identically, this time relying on the saved sub identifier rather than the e-mail address.
Common problems
The provider reports a redirect URI mismatch
The Redirect URI entered at the provider must match https://dockray.io/sso/{identifier}/callback character for character, where the identifier is exactly the one entered in the DockRay configuration. A typo in the identifier, a missing scheme, or an address copied for a different environment are the most common causes of this error.
Login fails despite a correct password at the provider
Check whether the provider actually returns email_verified: true in the ID token. DockRay rejects a login without that confirmation, even when everything else checks out - that is a deliberate boundary, not excessive caution: without a confirmed address there is no safe way to match an account.
The issuer address gets rejected when saving the configuration
DockRay only accepts public HTTPS addresses - a private, reserved, or internal-network address gets rejected before the integration ever tries to connect. The same applies to the addresses returned by the provider's discovery document: if any endpoint (authorization, token, JWKS) is not publicly reachable, login fails.
'User not found' despite an active account at the provider
SSO never creates accounts - it only logs in an existing user from the correct scope. Check two things: whether a DockRay user with that confirmed e-mail address exists at all, and whether you are signing in through the right scope - a platform configuration only finds Dock staff, and an account configuration only finds that account's users, even when the e-mail address is identical on both sides.
Login stopped working although the configuration looks the same
For a subscriber account, check whether it still has the enterprise SSO component purchased - dropping to the free plan turns off login this way immediately, not just hiding the button. If the configuration's issuer address changed recently, check that too: changing the issuer removes the old bindings between users and their accounts at the provider, so the first login after such a change goes through e-mail matching all over again.
Still not working
Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.