JWTs let you authenticate without a session store; sessions let you revoke immediately. Both have a place. The decision turns on revocation needs, latency tolerance, and how much data you want in the token itself.
How sessions work
Server creates a random session ID, stores it server-side (Redis, DB) with user details, returns ID to client as cookie. Every request: server looks up session in store. Trivial to revoke (delete the row). Latency: one Redis hop per request.
How JWTs work
Server signs a token containing user claims (id, role, expiry). Client stores it. Every request: server validates signature, reads claims locally — no store lookup. Stateless = horizontal scaling without sticky sessions. Latency: signature verify only (~10-50µs).
Revocation is the hard part
JWT can't be revoked before expiry without a blacklist (which makes it stateful again). Mitigations: short expiry (5-15 min) + refresh token rotation. Sessions revoke instantly by deleting the row. If you need 'log me out everywhere now,' sessions win unless you accept the blacklist trade-off.
Don't put sensitive data in JWT body
JWT bodies are signed, not encrypted by default — anyone can decode them with base64. Use JWE (encrypted) if you need confidentiality, or just don't put sensitive claims in there. User ID and role are fine; email and SSN are not.
Practical decision
Microservices needing stateless auth: JWT with 15-min expiry + refresh. Monolith or small service with Redis already: sessions, simpler operationally. Anything regulated (HIPAA, PCI) with strict revocation requirements: sessions or JWT + blacklist.