JWT

How it works

A JWT (JSON Web Token, RFC 7519) is a compact, URL-safe token made of three base64url-encoded parts separated by dots: a header, a payload of claims, and a signature. The signature (typically HMAC with a shared secret, or RSA/ECDSA with a public/private key pair) lets a recipient verify that the claims were not tampered with. Claims include registered fields like iss, sub, aud, exp, and iat, plus any custom data. Because the signature proves integrity, a verifier can trust a JWT without a database lookup. OIDC ID tokens are JWTs.

When it matters

JWTs matter whenever you need stateless, verifiable claims passed between parties: an OIDC ID token, an API access token, or a session token. They shine when you want to avoid a round-trip to a session store on every request. They are used across OAuth 2.0 and OIDC flows. Understand them before you design token handling. See OAuth 2.0 vs OIDC vs SAML.

Common misconceptions

• "JWTs are encrypted." By default a signed JWT (JWS) is only signed, not encrypted. Anyone can decode and read the payload. Do not put secrets in it unless you use JWE.
• "JWTs are easy to revoke." They are not. A signed JWT is valid until it expires, so use short lifetimes plus refresh tokens rather than long-lived JWTs.
• "`alg: none` is fine." Never accept unsigned JWTs; pin the expected algorithm.