An ID token is a JWT with a specific job: it tells *your client* who the user is. It is not an API credential, and sending it to your backend as one is the most common OIDC mistake.
What it is and is not
The OIDC flow issues two things. The ID token is proof of authentication, for your client, containing identity claims. The access token is proof of authorisation, for your API, containing scopes.
Send the access token to your API. If you send the ID token instead, your API is validating a credential that was never scoped for it — and the audience check, if it is even implemented, will fail or be disabled to make things work.
The seven checks
This tool runs the validation an OIDC relying party must perform, and shows which pass:
isspresent and exactly matching the issuer from the provider's discovery document. Exact string match, including the trailing slash or its absence.subpresent. The only claim guaranteed stable for a user. Key your records onissplussub, never on email — emails change and get reassigned.audmatches your client ID. Without this, a token issued to a different application at the same provider is accepted.expin the future. ID tokens are short-lived by design.noncematches the value you sent in the authorisation request. This binds the token to your request and prevents replay of a token captured elsewhere.algis asymmetric. RS256 or ES256. A provider offering HS256 for ID tokens is asking every client to hold a signing key.email_verifiedis true, if you use email at all. Matching accounts on an unverified address lets an attacker register an account claiming someone else's email and take over theirs.
Signature verification is separate
This tool validates claims. Verifying the signature requires the provider's public key from its JWKS endpoint — paste it into the JWT decoder, which performs full RS/ES verification. Both steps are required; neither substitutes for the other.
In production, use a certified OIDC library. Hand-rolled validation misses cases — JWKS key rotation, kid matching, algorithm pinning — that libraries have already got wrong once and fixed.
Claims worth reading
auth_time— when the user actually authenticated, which may be much earlier thaniatif the session was silently renewed. Check it before authorising anything sensitive.amr— the authentication methods used. Look formfabefore granting elevated access.acr— the assurance level, if your provider populates it.
Frequently asked questions
Can I send the ID token to my API?
You can, and it usually works, which is why the mistake persists. It is wrong: the audience is your client, not your API, so a correct API rejects it. Use the access token.
What if there is no nonce claim?
Then your authorisation request did not send one, and the token cannot be bound to your request. Send a nonce in the authorisation request and verify it here. It is a required defence in the implicit and hybrid flows.
Why must I check email_verified?
Because otherwise an attacker registers with a provider using a victim's email address, and if your application matches accounts on email, they inherit the victim's account. This has been a real vulnerability in multiple products.
How often should I re-validate?
On every use. An ID token is not a session — validate it once at sign-in, establish your own session, and do not treat the token as a long-lived credential.