How do JWTs work, and what security pitfalls should you watch for?
Short answer
A JWT is three base64url parts — header, payload (claims), and signature — joined by dots. The server signs the header and payload with a secret or private key, and verifies that signature on each request to trust the claims without server-side session state. Pitfalls: accepting alg=none, RS256-to-HS256 key confusion, not validating expiry/issuer/audience, putting secrets in the readable payload, and no revocation path.
JWTs come up constantly in appsec interviews because they are easy to use and easy to misuse. The interviewer wants to confirm you know they are signed, not encrypted, and that you can name the classic implementation traps.
How a JWT is structured
A JWT has three base64url-encoded parts separated by dots: a header (algorithm and token type), a payload of claims (subject, expiry, issuer, audience, roles), and a signature. The server creates the signature over the header and payload using either a shared secret (HS256) or a private key (RS256). On each request it recomputes/verifies that signature; if it's valid, the claims can be trusted without a server-side session lookup. That statelessness is the appeal — and the source of most problems.
The pitfalls
alg=none. Some libraries historically honored a header claiming "no signature," letting an attacker strip the signature and forge any claims. Always pin the expected algorithm server-side rather than trusting the header.- Key confusion (RS256 → HS256). If the server uses the RSA public key as an HMAC secret, an attacker can sign a forged token with that public key. Reject algorithm switching.
- Missing claim validation. A signature only proves the token wasn't tampered with — you must still check expiry (
exp), issuer (iss), and audience (aud). Tokens without expiry live forever. - Treating it as confidential. The payload is just base64, fully readable. Never put secrets in it.
- No revocation. Because JWTs are stateless, a stolen token is valid until it expires. Use short lifetimes plus refresh tokens, or a denylist for emergencies.
What interviewers look for
The header/payload/signature structure, "signed not encrypted," explicit algorithm pinning to kill alg=none and key confusion, validating exp/iss/aud, and an awareness that revocation is the hard part of stateless tokens.
Likely follow-ups
- Why is the alg=none vulnerability so dangerous and how do you prevent it?
- How does RS256-to-HS256 key confusion let an attacker forge tokens?
- How do you revoke a stateless JWT before it expires?