Questions
11 of 13
1What attacks are possible against JWT implementations?
2Why is storing JWT in localStorage considered risky?
3What is the biggest drawback of JWT?
4JWT is stateless. Then how do you logout users?
5How would you implement refresh token rotation?
6Why not make access tokens valid for 30 days?
7Explain Access Token and Refresh Token architecture.
8User role changes from Admin to User. JWT still says Admin. What do you do?
9How would you revoke millions of JWTs instantly?
10How do you revoke JWTs?
11LocalStorage vs HttpOnly cookies?
12RS256 vs HS256?
13How do role changes propagate?
JWTJWT
Basics
Structure
Claims
Security
Implementations
Microservices
11 / 13

LocalStorage vs HttpOnly cookies?

HttpOnly cookies are more secure than localStorage for storing authentication tokens because they are inaccessible to JavaScript, mitigating XSS attacks, but require CSRF protection.

localStorage is vulnerable to XSS because any injected script can read the token and exfiltrate it. HttpOnly cookies cannot be read by JavaScript, preventing XSS token theft. However, cookies are automatically sent with every request, making them susceptible to CSRF unless mitigated (e.g., SameSite=Strict, CSRF tokens). For SPAs, using HttpOnly cookies with SameSite=Strict and a CSRF token provides the best security. localStorage is simpler but riskier, especially for high-value applications.

Comparison
  1. 1

    localStorage: Accessible via JavaScript → XSS risk. No CSRF risk (since token sent manually in Authorization header).

  2. 2

    HttpOnly cookie: Not accessible via JavaScript → XSS safe. Requires CSRF protection (SameSite, CSRF tokens).

  3. 3

    Recommendation: Use HttpOnly cookies with SameSite=Strict and short-lived tokens. For SPAs, combine with backend authentication.