JSON Web Token
JWT.
A compact URL-safe means of representing claims to be transferred between parties, encoded as a signed (JWS) or encrypted (JWE) JSON object per RFC 7519.
JWTs are widely used and widely misused. The most common JWT mistakes in production: accepting JWTs without verifying the signature, accepting tokens with the alg header set to "none," failing to validate the audience or issuer, and treating JWTs as session-revocation-capable when they are not. For session tokens, opaque server-side sessions remain a defensible choice; for OIDC ID tokens and OAuth access tokens, JWT is the de-facto format.
Common questions
Are JWTs always signed?
No. A JWT can be signed (JWS), encrypted (JWE), or unsecured (the alg none, which should never be accepted). In practice authentication tokens are almost always signed so the recipient can verify integrity and origin; encryption is added when the claims themselves are sensitive.
What's the difference between an access token and an ID token?
An ID token proves a user authenticated and is meant for the client app to read; an access token is a credential the client sends to APIs to authorize requests. ID tokens are an OIDC concept, access tokens come from OAuth. Do not send ID tokens to APIs or treat access tokens as proof of login.
Should I use JWT or opaque tokens for sessions?
Opaque tokens, a random reference checked against server state, are usually the safer default for sessions because they can be revoked instantly. JWTs are self-contained and scale without a lookup, but are hard to revoke before expiry, so keep their lifetime short and pair them with a rotation or revocation strategy if you use them for sessions.