JWTs vs Sessions: The Auth Debate That Refuses to Die

JWTs became the default recommendation for new APIs somewhere in the last decade, often for reasons that don't apply to the app asking. They solve a real problem — stateless auth across services that can't share a session store — and get reached for by plenty of monoliths that never had that problem in the first place.

• Single monolith, one database → sessions are simpler, revocable instantly, and just as secure when done right.
• Multiple services or serverless functions that can't share state → JWTs solve a real problem here.
• JWT revocation before expiry needs its own denylist store — at which point you've partially rebuilt sessions anyway.
• Short-lived access tokens plus refresh tokens is the pattern that actually gets JWT security right in practice.

The security profile of both, done correctly, is comparable. The mistake isn't picking either — it's picking JWTs because they sound more modern, then discovering the revocation and payload-size problems six months into production.

Sessions aren't legacy. They're the right tool for the very common case JWTs get reached for out of habit.