1001Ferramentas
📖Dev

OIDC Standard Claim Lookup

Type a claim name such as sub, email_verified, azp or amr and see what OpenID Connect says it carries; names outside the spec are flagged as custom.

Descrição

What each standard OpenID Connect claim means

OpenID Connect standardises a set of claims — the fields describing the user inside an identity token. Standardising matters because it lets you swap providers without rewriting the application: the field identifying a person is called the same thing at Google, at Keycloak and at Auth0. Outside that set, every provider invents whatever it likes.

Pick the claim and the page explains what it carries. The most important is the subject identifier: it is the only one guaranteed unique and stable per user within that issuer, and it is what the application should tie its local record to. The rest are informational and can change — the email included.

Two recurring traps. The first is using the email as an identifier: it changes, it can be reassigned to another person on a corporate domain, and the field saying whether it was verified is usually ignored. The second is assuming every claim always arrives: most depend on the requested scope and on what the provider decides to return, so the application has to tolerate absence.

Frequently asked questions

Which claim should I use as the identifier?
The subject identifier, combined with the issuer. Uniqueness is guaranteed only within one issuer, so an application accepting several providers needs the pair. Using the subject alone opens the door to collisions between different providers.
Why does the email not work as a key?
Because it changes and can be reassigned. Someone changes their email and loses the account; a corporate address belonging to a leaver is reassigned and the new person inherits the access. Keep the email as contact data, and tie identity to the subject identifier.
Does every claim always arrive in the token?
No. What arrives depends on the requested scopes, the client configuration and the provider's decisions. Some providers return the minimum in the token and require a call to the userinfo endpoint for the rest. The application has to handle absence without breaking.

Related Tools