Jwt

---
name: JWT
slug: jwt
version: 1.0.1
description: Implement secure JWT authentication with proper validation, token lifecycle, and key management.
metadata: {"clawdbot":{"emoji":"🔐","os":["linux","darwin","win32"]}}
---

## Quick Reference

| Topic | File |
|-------|------|
| Algorithm selection | `algorithms.md` |
| Token lifecycle | `lifecycle.md` |
| Validation checklist | `validation.md` |
| Common attacks | `attacks.md` |

## Security Fundamentals

- JWTs are signed, not encrypted—anyone can decode and read the payload; never store secrets in it
- Always verify signature before trusting claims—decode without verify is useless for auth
- The `alg: none` attack: reject tokens with algorithm "none"—some libraries accepted unsigned tokens
- Use strong secrets: HS256 needs 256+ bit key; short secrets are brute-forceable

## Algorithm Choice

- HS256 (HMAC): symmetric, same key signs and verifies—good for single service
- RS256 (RSA): asymmetric, private key signs, public verifies—good for distributed systems
- ES256 (ECDSA): smaller signatures than RSA, same security—preferred for size-sensitive cases
- Never let the token dictate algorithm—verify against expected algorithm server-side

## Required Claims

- `exp` (expiration): always set and verify—tokens without expiry live forever
- `iat` (issued at): when token was created—useful for invalidation policies
- `nbf` (not before): token not valid until this time—for scheduled access
- Clock skew: allow 30-60 seconds leeway when verifying time claims

## Audience & Issuer

- `iss` (issuer): who created the token—verify to prevent cross-service token theft
- `aud` (audience): intended recipient—API should reject tokens for other audiences
- `sub` (subject): who the token represents—typically user ID
- Token confusion attack: without aud/iss validation, token for Service A works on Service B

## Token Lifecycle

- Access tokens: short-lived (5-15 min)—limits damage if stolen
- Refresh tokens: longer-lived, stored securely—used only to get new access tokens
- Refresh token rotation: issue new refresh token on each use, invalidate old one
- Revocation is hard—JWTs are stateless; use short expiry + refresh, or maintain blacklist

## Storage

- httpOnly cookie: immune to XSS, but needs CSRF protection
- localStorage: vulnerable to XSS, but simpler for SPAs
- Memory only: most secure, but lost on page refresh
- Never store in URL parameters—visible in logs, history, referrer headers

## Validation Checklist

- Verify signature with correct algorithm (don't trust header's alg)
- Check `exp` is in future (with clock skew tolerance)
- Check `iat` is not unreasonably old (optional policy)
- Verify `iss` matches expected issuer
- Verify `aud` includes your service
- Check `nbf` if present

## Common Mistakes

- Storing sensitive data in payload—it's just base64, not encrypted
- Huge payloads—JWTs go in headers; many servers limit header size to 8KB
- No expiration—indefinite tokens are security nightmares
- Same secret across environments—dev tokens work in production
- Logging tokens—they're credentials; treat as passwords

## Key Rotation

- Use `kid` (key ID) claim to identify which key signed the token
- JWKS (JSON Web Key Set) endpoint for public key distribution
- Overlap period: accept old key while transitioning to new
- After rotation, old tokens still valid until they expire—plan accordingly

## Implementation

- Use established libraries—don't implement JWT parsing yourself
- Libraries: `jsonwebtoken` (Node), `PyJWT` (Python), `java-jwt` (Java), `golang-jwt` (Go)
- Middleware should reject invalid tokens early—before any business logic