JWT vs Session Cookies

Revoking a session cookie is immediate and simple: delete (or invalidate) the corresponding row in the server's session store, and the next request using that session ID fails instantly, regardless of the cookie's own expiration.

Revoking a JWT before its own expiration is the core unsolved tension in the stateless design: because a valid signature is all a server checks, a token remains 'valid' from a pure cryptographic-verification standpoint until it expires, even if you want it dead right now (a user logging out, a compromised account, a permission downgrade). The common mitigations — a server-side denylist of revoked token IDs (the jti claim), or very short-lived access tokens paired with a separate, revocable refresh token — both reintroduce server-side state specifically to solve this, which is worth being honest about: 'fully stateless' JWTs and 'instant revocation' are in direct tension, and most real systems that need both end up building something that looks a lot like session storage anyway, just for revocation status instead of full session data.

A JWT stored in browser localStorage or sessionStorage is directly readable by any JavaScript running on the page — including malicious script injected via a cross-site scripting (XSS) vulnerability anywhere else on the site. An XSS bug anywhere means an attacker can simply read the token out of storage and impersonate the user.

Storing the JWT in an HttpOnly cookie instead (inaccessible to JavaScript entirely) closes that specific XSS-theft vector — but this is exactly the point worth being precise about: an HttpOnly-cookie-stored JWT is now exposed to the same cross-site request forgery (CSRF) risk a plain session cookie always had, since the browser will automatically attach the cookie to any request to that domain regardless of which site initiated it. At that point, you're carrying JWT's added complexity (parsing, signature verification, larger payload) while gaining essentially none of its stateless-verification advantage over a plain session cookie, and you still need the same CSRF mitigations (SameSite cookie attribute, anti-CSRF tokens) a cookie-based session would have needed anyway. This specific combination — JWT-in-cookie — is a common design smell worth naming directly rather than treating as a 'best of both worlds' default.

A plain session cookie marked HttpOnly is immune to JS-based theft the same way, and its CSRF exposure is mitigated the same way (SameSite=Lax/Strict, per RFC 6265's successor drafts, plus anti-CSRF tokens for state-changing requests) — without ever having introduced JWT's added complexity in the first place, if your architecture doesn't actually need cross-service stateless verification.

Session cookies assume a session store every authenticating service can reach — trivial in a monolith with one database, and still very manageable with a shared Redis instance across a moderate number of services. The cost is that every authenticated request pays a lookup, and that lookup infrastructure has to be available and fast for the whole system to function.

JWTs genuinely shine when multiple independently-deployed services need to verify a caller's identity without a shared session store or a network call back to an auth service for every request — a common microservices pattern where an identity provider issues a signed token once, and every downstream service verifies it locally using only a public key (see HMAC vs Digital Signatures for the HS256-vs-RS256 signing-algorithm choice this implies). This is the scenario where JWT's stateless design actually earns its complexity, rather than being adopted by default.