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.
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
- Header — Algorithm and token type
- Payload — Claims (data)
- 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:
- User logs in → receives access token (15min) + refresh token (7 days)
- Access token expires → use refresh token to get new access token
- Refresh token is single-use → rotation prevents replay attacks
Common Mistakes
- No expiration — Tokens that never expire are a security disaster
- Storing secrets in payload — JWT is encoded, not encrypted
- Not validating signature — Always verify before trusting claims
- 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
Related Articles
JWT Decoding Tutorial: How to Read and Debug JSON Web Tokens
Learn how to decode JWT tokens, understand their structure, debug authentication issues, and implement JWT security best practices in your applications.
API Security Checklist: 20 Points for 2024
Your API is probably leaking data. Here's my 20-point security checklist...
OAuth 2.0 Flows Explained: Which One Should You Use?
I've audited 50+ authentication implementations. 40% of them use the wrong OAuth flow...