JWT Backend Skill

Phase 1 — Discovery

Ask only what context doesn't reveal:

• Single service or multiple services? HS256 (shared secret) works for single service. RS256/ES256 (asymmetric) is required when multiple services need to verify tokens independently — each service gets the public key only.
• What's the token consumer? Browser (cookie storage viable), mobile (secure storage), or service-to-service (in-memory)? Storage recommendation differs significantly.
• Is logout/revocation required? JWTs are stateless — if you need revocation, you need a denylist. If you don't want that complexity, you're accepting that tokens are valid until expiry.
• Framework/language? Middleware integration pattern differs across Express, FastAPI, Rails, Go chi, etc.
• Session duration expectations? Short-lived access tokens (5–15 min) + long-lived refresh tokens is the correct architecture. If they want a single long-lived token, that's a design smell to address.

Phase 2 — Architecture Decisions

Algorithm selection (the part teams get wrong first)

Never use alg: none — some libraries accepted unsigned tokens when none was passed. Always explicitly whitelist the expected algorithm in validation: