Development2024-04-22

JWT Authentication: What Every Senior Engineer Expects You to Know

JSON Web Tokens are the backbone of modern API authentication. But most developers use them without understanding the security implications. Let's fix that.

#jwt#authentication#security#api#backend

We process日均百亿级 requests at the authentication layer. Every single one carries a JWT. If you don't understand exactly how these tokens work — their strengths, their weaknesses, and their failure modes — you're a liability to your team.

Let me give you the senior-level understanding.

JWT Structure

A JWT has three parts, separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4ifQ.abc123
  1. Header — Algorithm and token type
  2. Payload — Claims (data)
  3. Signature — Cryptographic proof of integrity

Each part is Base64url-encoded. Use a JWT Decoder to inspect any token's contents.

The Security Model

JWTs are signed, not encrypted. The payload is visible to anyone who intercepts it. The signature only proves that the token hasn't been tampered with.

This means:

  • ❌ Don't put passwords in JWT payloads
  • ❌ Don't put PII (personally identifiable information) in JWTs
  • ✅ Put user ID, roles, and expiration time
  • ✅ Use HTTPS always

Algorithm Confusion Attack

This is the attack that should keep you up at night:

// Attacker changes the algorithm header:
{"alg": "none", "typ": "JWT"}

If your library accepts alg: none, the attacker can forge any token without a signature. This vulnerability has been found in production at multiple Fortune 500 companies.

Fix: Always whitelist allowed algorithms on the server side. Never trust the alg header from the client.

Token Storage: Where to Put JWTs

Storage XSS Risk CSRF Risk Recommendation
localStorage ✅ Vulnerable ❌ Safe ❌ Not recommended
sessionStorage ✅ Vulnerable ❌ Safe ❌ Not recommended
httpOnly Cookie ❌ Safe ✅ Vulnerable ✅ With CSRF token
Memory (variable) ❌ Safe ❌ Safe ✅ Best, but lost on refresh

My recommendation: httpOnly Secure SameSite=Strict cookies with CSRF protection.

Refresh Token Strategy

Access tokens should be short-lived (15 minutes). Use refresh tokens for session continuity:

  1. User logs in → receives access token (15min) + refresh token (7 days)
  2. Access token expires → use refresh token to get new access token
  3. Refresh token is single-use → rotation prevents replay attacks

Common Mistakes

  1. No expiration — Tokens that never expire are a security disaster
  2. Storing secrets in payload — JWT is encoded, not encrypted
  3. Not validating signature — Always verify before trusting claims
  4. Using symmetric keys in distributed systems — Use RS256 (asymmetric) for microservices

Debugging JWTs

When debugging auth issues, paste your token into a JWT Decoder to inspect:

  • Is the expiration correct?
  • Are the claims what you expect?
  • Is the algorithm what your server expects?

Decode and inspect JWT tokens with our free JWT Decoder — shows header, payload, and signature details. Runs entirely in your browser.

🛠

Try It Yourself

Put what you've learned into practice with our free online tools.

Explore More Developer Tools

Discover more tools and tutorials in this category

Browse Category →