ID Token
A security token that contains verifiable claims about an authenticated user.
Detailed Explanation
Defined in the OpenID Connect spec, the ID Token is a JWT that provides information like the user's name, email, and ID. It is intended to be read by the client application to personalize the UI or verify identity. It should not be used as an access token for authorization on the backend.
Quick Summary
An ID token is a JWT issued by an OIDC provider that tells the *client* who the user is. It is for identity, not for authorization, using it to call APIs is a common, dangerous mix-up.
Key Takeaways
- Standard claims: `iss`, `sub`, `aud`, `exp`, `iat`, `nonce`, plus profile claims like `email`, `name`.
- Always validate signature (against the provider's JWKS), `iss`, `aud` (your client ID), `exp`, and `nonce`.
- Intended audience: the client app, not the API. ID tokens shouldn't be sent in `Authorization` headers to your backend.
- Short-lived; obtained alongside an access token during OIDC login.
- The `sub` claim is the stable user identifier, prefer it over email for keying users.
When to use it
- Personalizing the UI after "Sign in with Google/Apple", name, avatar, locale.
- Verifying user identity to your backend by passing the ID token once, exchanging it for a server-issued session.
- Federated SSO: every downstream app trusts the same OIDC ID token from a central IdP.
Common Mistakes
- Using the ID token as an API access token, the API isn't the intended audience, and the token can't be revoked usefully.
- Decoding without verifying, base64-decoding the JWT is not validation.
- Trusting `email` as a stable user ID; users change emails, and some IdPs reuse them.
- Missing `nonce` validation, which is the primary defense against replay.
ID Token, Frequently Asked
Why not just use the ID token everywhere?
Because its audience is the client. Resource servers should require access tokens scoped to them. Mixing the two leaks identity claims to APIs that shouldn't have them and breaks revocation semantics.
Where should I validate the ID token?
Client-side after the OIDC flow completes (signature, claims, nonce). If you pass it to your backend for a server-issued session, validate it again there before trusting any claim.