JWT — 3 Parts, Signing, Revocation

SecurityMidsecurity

The Question

What are the three parts of a JWT? How are they signed and revoked?

What a Strong Answer Covers

• header.payload.signature
• "stateless
• "can't revoke
• revocation strategy

Senior-Level Answer

A JSON Web Token (JWT) is a compact, self-contained token format for transmitting claims between parties. It consists of three base64url-encoded parts separated by dots: header.payload.signature.

The header is a JSON object specifying the token type and signing algorithm: `{"alg": "HS256", "typ": "JWT"}`. Common algorithms: HS256 (HMAC-SHA256, symmetric key), RS256 (RSA-SHA256, asymmetric key pair), ES256 (ECDSA, asymmetric). The algorithm choice has security implications.

The payload contains claims — key-value assertions about the subject. Registered claims are standardized: `iss` (issuer), `sub` (subject/user ID), `exp` (expiration timestamp), `iat` (issued-at), `aud` (audience — which service this token is for). Custom claims add application-specific data: roles, permissions, user metadata. The payload is base64url-encoded but not encrypted — anyone can decode and read it. Never store sensitive data (passwords, PII) in JWT payloads unless the token is also encrypted (a JWE).

The signature is computed over the encoded header and payload: `HMAC-SHA256(base64url(header) + '.' + base64url(payload), secret)` for HS256. The server verifies the signature on each request to ensure the token hasn't been tampered with. If any part of the header or payload changes, the signature no longer matches.

For signing algorithm selection: HS256 uses one shared secret — simple but both issuer and verifier must know the secret, which is risky if multiple services verify tokens. RS256/ES256 use private key for signing (auth server only) and public key for verification (any service) — better for distributed systems. A critical vulnerability to know: the `alg: none` attack — early JWT libraries accepted tokens with algorithm `none` and no signature; always explicitly validate the expected algorithm.

Revocation is JWT's hard problem. JWTs are stateless — validity is proven by signature alone, with no server-side lookup. A revoked JWT remains valid until it expires unless you add state. Common patterns: short expiry (5-15 minutes) plus refresh tokens; a token blocklist/denylist (store revoked JTI claims in Redis — brings back state but bounded to revoked tokens only); or opaque tokens for critical paths where immediate revocation is required. Logout in JWT-based systems is often a client-side delete (remove the token from storage) plus server-side blocklist of the specific token if revocation must be immediate.

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying the JWT payload is encrypted — it's base64url-encoded (trivially decodable), not encrypted unless using JWE.
• Not knowing the alg:none attack — this is a well-known vulnerability and a signal of how deeply the candidate understands JWT security.
• Treating logout as solved by deleting the client-side token — the token remains valid server-side until expiry; revocation requires additional server-side state.
• Not knowing the difference between HS256 and RS256 in terms of key distribution — significant for microservices architectures.

Follow-Up Questions

• What is the alg:none attack and how do you prevent it? — Malicious JWT with alg:none and no signature. Vulnerable libraries accepted it. Prevention: always explicitly specify expected algorithms in verification; reject if alg doesn't match.
• How would you implement immediate JWT revocation without storing all issued tokens? — Maintain a JTI (JWT ID) blocklist of revoked tokens in Redis with TTL equal to the token's remaining expiry. Small bounded set — only actively revoked tokens, not all issued tokens.
• What is the difference between a JWT and an opaque token? — JWT is self-contained — verifiable without DB lookup. Opaque token is a random string that requires server-side lookup. JWT is faster (no I/O) but can't be immediately revoked; opaque can.
• Why should the audience (aud) claim be validated? — Without aud validation, a token issued for service A could be replayed against service B. aud ensures a token intended for one service isn't accepted by another, even if both share the same signing key.

Related Questions

• Authentication vs Authorization
• SQL Injection
• CSRF
• XSS
• OAuth 2.0 — Authorization Code Flow