JWT

Contains metadata about the token: the signing algorithm (alg) and token type (typ). Always Base64url-encoded JSON. The algorithm choice here affects the security of the entire token.

{
  "alg": "HS256",
  "typ": "JWT"
}

Contains the claims: statements about the user and additional metadata. Also Base64url-encoded JSON. Anyone can decode this — payload data is NOT encrypted, only signed.

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

A cryptographic signature over the encoded header and payload. Verifying this signature ensures the token was not tampered with. The secret key (HMAC) or private key (RSA/ECDSA) is never included in the token.

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

Uses a shared secret key for both signing and verification. Simple to implement but requires all verifiers to know the secret.

Uses a private key to sign and a public key to verify. The private key never leaves the auth server.

Like RSA but with smaller keys and faster signing. Provides equivalent security with better performance.

No signature at all. A token with alg:none has no integrity guarantee and can be forged by anyone.

Some libraries accept tokens with alg:none (no signature). An attacker can modify the payload and set alg to none to forge any JWT. Always explicitly specify and validate the allowed algorithm.

If a library is expected to verify RS256 but accepts HS256, an attacker can sign a token using the public key as the HMAC secret. The library verifies it successfully. Always pin the expected algorithm.

A JWT without an exp claim, or code that does not check exp, allows tokens to be used indefinitely after a user logs out or is banned. Always set short expiration times and validate the exp claim.

JWT payloads are Base64-encoded, not encrypted. Anyone who intercepts a JWT can decode and read the payload. Never store passwords, credit card numbers, or other secrets in JWT claims.

HMAC-signed JWTs with short or predictable secrets can be brute-forced offline. An attacker who obtains a JWT can try billions of keys per second. Use cryptographically random secrets of at least 256 bits.

Accepting JWTs without verifying the signature trusts the payload completely. This is a critical bug that allows any user to craft arbitrary claims. Always verify the signature before trusting any claim.

Standard JWTs (JWS — JSON Web Signature) are signed but NOT encrypted. The payload is Base64url-encoded, which is trivially reversible. Anyone who obtains a JWT can read its contents. JWE (JSON Web Encryption) provides encryption, but is much less common.

Access tokens should be short-lived: 5–60 minutes is typical. Long-lived tokens are dangerous because they cannot be revoked without a token blocklist. Use refresh tokens (longer-lived, stored securely) to obtain new access tokens.

HttpOnly cookies are the most secure option — they are inaccessible to JavaScript, preventing XSS theft. localStorage is vulnerable to XSS attacks but avoids CSRF. Memory (JavaScript variable) is safest but does not survive page refresh. There is no perfect option.

Not without server-side state. The stateless nature of JWTs means the server cannot invalidate them. Solutions: short expiration times, a token blocklist (Redis), rotating refresh tokens, or switching to opaque session tokens for sensitive operations.

Session cookies store a random session ID; the server looks up session data. JWTs are self-contained — the server validates the signature without a database lookup. JWTs scale better across multiple servers but cannot be revoked without extra infrastructure.

The minimum: sub (user ID), exp (expiration), and iat (issued at). Add iss (issuer) for multi-service setups. Keep payloads small — JWTs are sent with every request. Do not include sensitive data or large profile objects.

RS256 (asymmetric) is better for most production systems because only the auth server needs the private key. Multiple services can verify tokens using the public key without sharing a secret. HS256 is simpler but requires all verifiers to know the shared secret.

PKCE (Proof Key for Code Exchange) is an extension to the OAuth2 authorization code flow that prevents authorization code interception attacks. It is required for public clients (SPAs, mobile apps) that cannot securely store a client secret.