Sessions vs JWT: revocation, rotation, and where the state lives on serverless

A session is a pointer; a JWT is a copy

Before you pick an auth strategy, ask yourself one question: what happens when you need to terminate an active session right now, not in an hour? The answer separates sessions from JWTs more cleanly than any performance benchmark.

A stateful session stores nothing meaningful in the browser. The cookie carries an opaque random token — 128 bits of entropy minimum, in practice 256 from crypto.randomBytes(32) — and the server keeps a record mapping that token to the user id, expiry, and metadata. Every authenticated request does one store lookup. The payoff is operational control: revocation is deleting a row, effective on the very next request. “Log out everywhere” is deleting all rows for a user. Rotation — issuing a fresh token and invalidating the old one — happens on login and on privilege escalation, which is the standard defense against session fixation: an attacker who planted a token before login holds a pointer to nothing after it.

A JWT inverts this: the claims travel with the request — header.payload.signature — and verification is local math: check the signature, check exp, done. No store, no lookup, no shared infrastructure between issuer and verifier. The price is symmetric: the server kept no state, so there is no state to delete. A stolen JWT is valid until exp no matter what you do, unless you check every request against a server-side denylist — at which point you have rebuilt a session store and kept the JWT parsing on top. The honest stateless mitigation is short-lived access tokens (5–15 minutes) plus a refresh token that is checked against the database, with rotation and reuse detection: the revocation window shrinks to the access token’s TTL instead of disappearing.

// app/lib/session.ts
import { cookies } from 'next/headers';
import { randomBytes } from 'node:crypto';
import { kv } from '~/lib/kv';

export async function createSession(userId: string) {
  const token = randomBytes(32).toString('hex'); // 256 bits — unguessable, meaningless
  const maxAge = 60 * 60 * 24 * 7;
  await kv.set(`session:${token}`, { userId, createdAt: Date.now() }, { ex: maxAge });

  (await cookies()).set('__Host-session', token, {
    httpOnly: true,   // JS can never read it — XSS cannot exfiltrate the cookie
    secure: true,     // required by the __Host- prefix
    sameSite: 'lax',  // cross-site POSTs do not carry it
    path: '/',        // required by the __Host- prefix
    maxAge,
  });
}

export async function revokeSession(token: string) {
  await kv.del(`session:${token}`); // dead on the next request — this is the whole point
}

Cookie attributes are half the security model

When you look at a session cookie in the browser’s devtools, you are looking at a security contract written in four attributes. Miss one, and that contract has a hole an attacker can walk through.

Whichever token you choose, in a browser it should live in a cookie with the full attribute set, because each attribute closes a real attack. HttpOnly makes the cookie invisible to JavaScript — an XSS payload cannot exfiltrate it (be honest about the limit: XSS can still act as the user by firing same-origin requests; HttpOnly stops theft, not abuse). Secure keeps it off plaintext HTTP. SameSite=Lax — the default worth keeping — means cross-site POSTs do not carry the cookie at all, which is your first CSRF layer; only top-level GET navigations send it, which is why a GET handler that mutates state is a self-inflicted CSRF hole.

The underrated one is the __Host- prefix. A cookie named __Host-session is only accepted by the browser if it is Secure, has path=/, and has no Domain attribute — meaning it is host-locked. Compare that to the legacy pattern Domain=.example.com: now any subdomain can read and, worse, set that cookie. One compromised status.example.com — an abandoned marketing microsite, a vulnerable third-party tool on a subdomain — can plant a session cookie on the parent domain (cookie tossing) and walk a victim into an attacker-controlled session. The __Host- prefix turns that whole class off with a naming convention the browser enforces.

Where the store lives on serverless

Sessions need a store, and on serverless that store cannot be process memory. A module-level Map works flawlessly in next dev — one long-lived process — and then produces ghost bugs in production: each function instance has its own memory, instances run in parallel and are recycled without notice. Login writes the session into instance A; the next request lands on instance B and looks like a logged-out user; deploys wipe everything. The store must be external, and the realistic options have honest numbers attached. A region-local Redis/KV (Upstash, Vercel KV) answers in roughly 1–2 ms p50 — the cheapest authenticated-request tax you can buy, though p99 over HTTP-based KV can stretch to 10+ ms. A Postgres sessions table costs 5–15 ms and adds connection-pool pressure from functions, but gives you transactions and one fewer system. Encrypted-cookie sessions (the iron-session pattern) need no store at all — and have exactly the JWT revocation problem with a different codec, since the server again keeps nothing it can delete.

Against that, a JWT HMAC verification is tens of microseconds of CPU and zero IO. That gap — ~1 ms versus ~0.05 ms — is real but rarely decisive for a dashboard; it becomes decisive when verification happens on a CDN edge for every request, or across services that cannot share a store. The hybrid most teams converge on: short-lived JWT access token (5–15 min) verified locally, refresh token in the store. The revocation window equals the access TTL — write that sentence into your security docs, because it is the number the auditor will ask about. If the requirement is “terminate access within 60 seconds,” your access token lives ≤60 seconds and you are hitting the store every minute anyway — at which point plain sessions are the simpler system with the same cost.