JWT Security — Signing, Expiry, and Refresh Token Rotation
Fast recall
Quick revision
Core answer
alg from the token header — pin it), `alg: none` (always reject), `localStorage` storage (XSS-readable — use HttpOnly cookies), and JWT `jti` blocklist in Redis for explicit revocation/logout.Whether the candidate understands JWT's stateless nature, the implications of not being able to revoke tokens, and strategies to mitigate token theft.
Using the 'none' algorithm, setting very long expiry times, or storing JWTs in localStorage without understanding XSS risk.
Discuss the algorithm confusion attack (RS256 vs HS256 key confusion), token blocklist for logout, and the security trade-off of short-lived tokens.
Interview-ready guide
Interview answer
Signing algorithm choice
- HS256 (HMAC): symmetric, same secret signs and verifies; all services need the secret; simpler for single service
- RS256 (RSA): asymmetric, auth server signs with private key, resource servers verify with public key from JWKS
- ES256 (ECDSA): asymmetric, smaller keys, faster than RSA; modern preferred
Algorithm confusion attack
- Attacker crafts token with
alg: none-> no signature - Vulnerable libraries derive algorithm from token header
- Fix: pin the expected algorithm in validator config
Expiry strategy
- Access token 15-min TTL — short exposure window
- Refresh token 7-30 days,
HttpOnlycookie - Rotation: each refresh issues new + revokes old; reuse of revoked = theft signal -> revoke family
Revocation
- Store revoked
jtiin Redis with TTL = remaining valid time - Check on every request — one Redis lookup
- Enables instant logout and compromise response
Storage rules
HttpOnlycookie -> XSS-safe; needs CSRF protectionlocalStorage-> XSS-readable; never for tokens- For SPAs: short access in memory + refresh in
HttpOnlycookie
Common mistakes
alg: noneaccepted by older libraries- Algorithm confusion (RS256 -> HS256 with public key as secret)
- Long-lived access tokens (hours) without refresh
- PII in claims (base64 visible)
- HS256 secret leaked from one of many services
Operational checklist
- Pin algorithm; reject
alg: none - Validate
iss,aud,exp,nbf, signature - Use RS256/ES256 + JWKS for multi-service
- Refresh rotation for theft detection
- JTI blocklist for explicit revocation
JWT Security — Signing, Expiry, and Refresh Token Rotation
Direct Answer
JWTs must be signed with a strong algorithm (RS256/ES256 or HS256 with a secure key) to prevent forgery. Access tokens should be short-lived (5-15 min); refresh tokens enable session continuity. Refresh token rotation — new refresh token per use, old one invalidated — provides automatic theft detection: reuse of an invalidated token signals compromise and the entire family is revoked. The biggest pitfalls: algorithm confusion attack (never trust alg from the token header — pin it), alg: none (always reject), localStorage storage (XSS-readable — use HttpOnly cookies), and JWT jti blocklist in Redis for explicit revocation/logout.
Common Mistakes & Pitfalls
Using the 'none' algorithm, setting very long expiry times, or storing JWTs in localStorage without understanding XSS risk.
Check your understanding
Answer these without looking back at the article.
- What is the algorithm confusion attack in JWT and how do you prevent it?
- How would you implement logout for a stateless JWT-based system?
- What is the difference between storing JWTs in localStorage vs HttpOnly cookies from a security perspective?
- How does refresh token rotation enable automatic compromise detection?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.