jargon

Comparison

JSON Web TokenvsSession cookie

JSON Web Token

the token itself carries the claims and a signature, so you can verify it without a database lookup on every request.

A signed, self-contained token carrying claims that any holder of the key can verify locally. That statelessness is the whole appeal and the whole problem: verification needs no round trip, and neither does revocation, which therefore does not exist. Keep expiry short, pair with refresh tokens, and never put anything in the payload you would mind the client reading.

signed tokenBrowserServerNothing tolook up
Full entry →

Session cookie

you give the browser an opaque id and keep the actual session state on the server, so logging someone out is one delete.

An identifier referencing server-held session state. Revocation is immediate and the client learns nothing, which is exactly what stateless tokens give up. The cost is a lookup per request and shared session storage across instances; the flags — `HttpOnly`, `Secure`, `SameSite` — are what make it safe in a browser.

session idlook up the idBrowserServerSessionstore
Full entry →

Related comparisons