JWT Structure

A JSON Web Token is three base64url-encoded segments separated by dots: header.payload.signature. The header names the algorithm (alg) and token type (typ). The payload carries claims — standardized ones like sub (subject), iss (issuer), exp (expiry seconds since Unix epoch), and iat (issued-at) — plus any custom fields your application needs.

Decoding vs. Verifying

Decoding reads the payload without checking the signature. Anyone can decode a JWT without the secret key — the data is encoded, not encrypted. Verification confirms the signature using the server's secret (HMAC) or public key (RSA/ECDSA). Always verify on the server; never trust a client-decoded JWT claim.

Common Security Mistakes

• alg: none attacks — Some old libraries accepted tokens with no signature if the header said "alg":"none". Always reject unsigned tokens explicitly.
• Storing JWTs in localStorage — XSS can read localStorage. HttpOnly cookies prevent JavaScript access. For sensitive apps, prefer cookie storage.
• Not checking exp — A valid signature on an expired token should still be rejected. Always validate the expiry timestamp on the server.
• Short-secret HMAC keys — HS256 with a short secret can be brute-forced. Use at least 256 bits of random entropy for HMAC keys, or switch to RS256 which uses a key pair.

When to Use JWTs

JWTs work well for stateless API authentication, short-lived access tokens, and passing verified claims between services. They work poorly as session tokens for long-lived web sessions — you cannot invalidate individual tokens without a server-side blocklist, which eliminates the stateless benefit.