Test login

Single sign-on → Test login.

Almost every SSO problem is one of three things: the issuer is not what you registered, the role claim did not resolve, or the values resolved but nobody mapped them. Test login distinguishes all three in one screen, which is faster than any amount of reasoning about it.

Two ways to run it

Paste a token. Runs the whole pipeline against a token you already have. Fastest when you can get one out of your provider’s own test tool.

Sign in for real. Starts a full authorization-code flow with PKCE against your configured provider, exchanges the code server-side, and stores the report. Use this when you want to prove the round trip, not just the token.

What the report tells you

• The complete claim set, verbatim — and a flag saying whether it was cryptographically verified. On a rejection the claims are shown unverified, which is exactly when you need to see them.
• The discriminator — which claim was read, the value in the token, the value your organisation is registered with, and whether they matched.
• The role claim — the configured name or path, whether it resolved at all (the Keycloak failure mode), the raw value, and per value whether it mapped or why it did not.
• The contribution of each of the four role sources, and the final set.
• Every validation step, pass or fail.
• Actionable hints derived from what actually failed.

Claim values are not redacted, and that is on purpose

A redacted diagnostic is a useless one — you cannot compare a value you cannot see. The endpoint is administrator-only for exactly this reason.

No token is ever logged or stored. Not in the application log, not in the audit log, not in the stored report.

Reading the three common outcomes

“Authenticated, roles: none”

Authentication is fine. Look at the role claim section:

• Claim did not resolve → you configured the wrong name or path. Keycloak needs realm_access.roles; Auth0 needs the exact namespaced string; Okta needs the groups claim to have been added in the first place.
• Claim resolved, values unmapped → the values arrived but your role map has no entry for them. Copy them out of the report into the map.

unknown-issuer

The provider mints a different issuer than you registered. Compare the iss in the report against the registration. Usual causes: a Keycloak realm path, an Okta custom vs Org authorization server, or a trailing slash.

discriminator-absent / discriminator-unmatched

For Google: you signed in with a personal account, or from a different Workspace domain. Comparison is trimmed and case-insensitive on both sides, so case is never the cause — do not spend time on it.

Error reference

Codes are stable and returned in the JSON body.

Code	Cause	Fix
unknown-issuer	Provider mints a different issuer than registered	Compare iss in the report with the registration
discriminator-absent	Shared issuer, token lacks the claim	Google: use a Workspace account. Otherwise configure the provider to emit it
discriminator-unmatched	Not onboarded under that value	Compare the raw value with the registration
verify-failed — aud	Token minted for a different API	Register the audience the provider actually mints. The hint prints both sides
verify-failed — signature / kid	Stale keys, or the token is not from the issuer it claims	Re-run discovery
verify-failed — exp	Expired token	Get a fresh one
verify-failed — alg not allowed	HS256 or none	Only asymmetric algorithms are accepted; with HS* the signing key is the client secret
discovery-failed — issuer mismatch	The document declares an issuer it was not served from	Refused deliberately. Fetch discovery from the issuer it declares
discovery-failed — not https	Plain-http metadata URL	https only — metadata decides which keys are trusted
discovery-failed — not valid JSON	You pasted a login or error page served with 200	Check the URL
idp-disabled	The registration is disabled	Re-enable it