JWT vs session authentication

July 10, 2026 · 16 min read

Teams polarize around JWTs versus classic server-side sessions. Both can be secure; the trade-off is where state lives, how revocation works, and how horizontally scaled APIs validate callers. This guide compares mechanics without declaring a universal winner.

How session authentication works

After login, the server stores session data (user ID, roles, CSRF token) in Redis, a database, or memory, and sends the browser a session ID in an HttpOnly, Secure cookie. Each request presents the cookie; the server looks up state. Logout deletes the row - revocation is immediate. The cookie is opaque; clients cannot read permissions without asking the server.

The stateless JWT model

The server issues a signed JWT containing claims. APIs validate the signature and expiry without a central session store - ideal for microservices that do not share Redis. Revocation is harder: you need short TTLs, refresh-token rotation, or a denylist checked on every request (which reintroduces state).

Session cookie flow:
  Browser --(session_id)--> API --> Session store --> User record

JWT bearer flow:
  Browser --(JWT)--> API --> Verify signature + claims (no store, unless denylist)

Side-by-side comparison

Revocation - Sessions win: delete the session. JWTs need short exp or explicit denylist.
Scale-out - JWTs win when every service can verify with a public key; sessions need shared session storage.
Payload size - Sessions send a small ID; JWTs repeat claims on every request.
XSS impact - JWT in JS-accessible storage is stealable; HttpOnly session cookies resist script theft.
Cross-domain - JWTs in Authorization headers suit SPAs and mobile; cookies need SameSite and CORS care.

Hybrid patterns that work in production

Common pattern: opaque refresh token in HttpOnly cookie plus short-lived JWT access token in memory for API calls. BFF (backend-for-frontend) servers mint JWTs after validating the session. Another pattern: session for web, JWT for service-to-service with mTLS.

How to choose for your product

Choose sessions when you need instant logout, simple mental model, and monolithic or cookie-based web apps. Choose JWTs when many services verify the same issuer, mobile clients call APIs directly, or you already run an OAuth/OIDC stack. If you choose JWTs, plan refresh rotation and never skip signature validation.

FAQ

Are JWTs always stateless?: Only if you do not consult a denylist or session version on each request. Many ‘JWT’ systems are stateless in name only.
Can I put a JWT in an HttpOnly cookie?: Yes. That combines bearer-token claims with cookie transport security. You still must mitigate CSRF for cookie-based auth.
Which is better for SPAs?: Often hybrid: HttpOnly refresh cookie + in-memory access JWT, or session with BFF. Avoid long-lived JWTs in localStorage.
Do sessions scale to microservices?: Yes with a shared Redis cluster or sticky sessions plus gateway session validation, but JWTs reduce repeated session fetches.

Related: Common JWT security mistakes

Browse all tools