JWT
A compact, signed JSON token (header.payload.signature) used to carry claims between parties. Signed tokens are verifiable offline; the catch is revocation. Common for API auth and OIDC ID tokens.
- Stateless API auth with short-lived tokens.
- OIDC ID tokens and service-to-service claims.
- Long-lived sessions needing revocation (use opaque session tokens + DB).
- Carrying sensitive data (use JWE or don't put it in a JWT).
Definition
A JSON Web Token is a base64url-encoded triple: header (alg), payload (claims like sub, exp, aud), and a signature (HMAC or RSA/ECDSA). Signed (JWS) tokens are integrity-protected; encrypted (JWE) variants hide claims.
Why it exists
To pass verifiable, self-contained assertions without a per-request DB lookup. The signer vouches for the claims; the verifier checks the signature and expiry.
How it works
Issuer signs claims with a key; verifier checks signature against a known key (or JWKS), then validates exp, aud, iss. Stateless verification is fast. Short-lived access tokens limit damage; refresh tokens renew them.
Scaling limits
Revocation before expiry breaks statelessness — you need a denylist (and lose the main benefit) or very short lifetimes. Large claims bloat every request. alg=none and key confusion are classic pitfalls.
Cost shape
Signature verification CPU per request (small). No DB lookup for stateless validation. Cost is key management and rotation.
Alternatives
- Opaque session tokens — Revocable and small, but need a DB/Redis lookup per request.
- PASETO — Safer versioned token format avoiding JWT alg pitfalls.
Failure modes
- Accepting alg=none or symmetric alg with a public key.
- No expiry or ignoring exp.
- Unrevocable long-lived tokens.