security
Session cookies vs JWTs
The debate is over. For browser auth in 2026, use encrypted session cookies.
For browser-facing authentication, the debate between stateful sessions and stateless JWTs has had a clear answer for years. Session cookies win. The reasons are not exciting.
Revocation#
A stateful session can be revoked in one UPDATE. A JWT cannot — the signature remains valid until the expiry you baked into the token, unless you build an allowlist or blocklist, at which point your JWT is stateful and you're back where you started.
Leakage#
A JWT in localStorage is an XSS gift. Anyone who can run a script on your origin reads the token and can impersonate the user from anywhere for the lifetime of the token. HttpOnly session cookies cannot be read by JavaScript — an XSS that would have stolen a token now only gets to perform one authenticated request.
Size#
Sessions carry a small opaque ID (20 bytes). JWTs carry claims, signatures, and often base64 bloat to 500+ bytes. On every request. Multiplied by every embedded resource. The mobile network you're not thinking about thanks you.
Encrypted cookies#
Our boilerplate uses iron-session — AES-256-GCM encrypted HttpOnly cookies with a rotating secret. Zero database round-trips for session lookup (the cookie IS the session), with the revocation story of a stateful system (rotate the key, everyone's out).
When JWTs are correct#
Service-to-service authentication with short-lived tokens. OAuth2 access tokens against third parties. Anywhere the consumer isn't a browser and token revocation isn't part of your operational model.