Read OpenID Connect claims correctly
OpenID Connect layers identity on top of OAuth 2.0 by returning claims about the
authenticated user. Some claims are protocol metadata in the ID token (iss,
sub, aud, exp, nonce); others describe the person and are released by
scope (profile, email, phone, address). This tool lists the standard
claims with their JSON data type, the scope that unlocks them, and where they
appear — the ID token, the UserInfo endpoint, or both.
How it works
When a client requests scopes during login, the authorization server releases the
matching claims after the user consents. The mandatory openid scope yields
sub, the stable user identifier. The profile scope releases display claims such
as name, given_name, picture, locale and updated_at; email releases
email and email_verified; phone releases phone_number and its verified
flag; and address releases a structured address JSON object. Protocol claims in
the ID token let the client validate the token: iss and aud must match the
expected issuer and client, exp bounds its lifetime, and nonce ties it back to
the original request to prevent replay. The same profile claims can be fetched
fresh from the /userinfo endpoint using the access token.
Tips and notes
Key your accounts on sub, never on email or preferred_username, both of which
can change or be reused. Check email_verified before trusting an address, and
remember address is a nested JSON object — read its formatted, country and
postal_code sub-fields rather than expecting a plain string. Request only the
scopes you genuinely need so the consent screen stays minimal and you collect less
personal data. Finally, always validate the ID token’s signature, iss, aud,
exp and nonce before trusting any claim inside it.