What are the standard registered JWT claims?

RFC 7519 defines seven registered claims: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at) and jti (JWT ID). They are optional but reserved with defined meanings, so do not repurpose them.

How do I validate exp and nbf?

exp and nbf are NumericDate values in seconds since the Unix epoch. Reject a token when the current time is at or after exp, or before nbf. Allow a small clock skew, typically 30 to 60 seconds, to tolerate clock drift between servers.

Why must I check the aud claim?

The aud claim names the intended recipients. If your service accepts a token whose aud is for a different service, you risk token confusion and replay attacks. Always verify that aud contains your service's identifier.

What is the difference between an ID token and an access token claim?

ID token claims like name, email and auth_time describe the authenticated user for the client. Access token claims like scope and client_id describe what the bearer is authorized to do at a resource server. Do not treat an ID token as an access token.

Should I trust the email claim?

Only when email_verified is true. The email claim alone is not proof of ownership, so gate any trust or account-linking on the email_verified boolean to avoid account takeover via unverified addresses.

JWT Claims Reference

JWT claims reference

A JSON Web Token carries its data as claims — name/value pairs inside the JSON payload. Some claim names are registered by RFC 7519 with precise meanings (iss, exp, aud), others are standardized by OpenID Connect for identity (email, nonce, auth_time), and the rest are public or private to your application. Verifying a token is mostly about validating these claims correctly: the wrong skew on exp, a skipped aud check, or trusting an unverified email are all real-world security holes. Search the reference above by claim name or keyword.

How it works

JWT claims live in the second segment (the payload) of a header.payload.signature token, base64url-encoded JSON. After verifying the signature with the issuer’s key, a validator must check the claims: exp and nbf are NumericDate integers (seconds since the Unix epoch) bounding the validity window; iss must match a trusted issuer; aud must include your service; and jti can be tracked to block replay. OpenID Connect layers identity claims on top — nonce ties an ID token to a specific auth request, auth_time supports max_age, and azp names the authorized party. Access tokens (RFC 9068) commonly add scope, client_id, and roles for authorization decisions.

Tips and examples

Always validate the trio that prevents misuse: signature, exp/nbf (with small skew), and aud. Skipping any one undermines the others.
Use sub as the stable user key, never email or preferred_username, which can change or collide.
For replay-sensitive flows, persist seen jti values until their exp so a token cannot be used twice.
Gate identity trust on booleans: rely on email_verified before linking accounts, and check azp equals your client_id when aud has multiple values.

JWT Claims Reference

Email me this result

JWT claims reference

How it works

Tips and examples