Skip to main content
Session vs Token Authenticationlesson 3 of 4 · 2 min read

The Hybrid Reality

What real deployments run

Real deployments rarely sit at either pole.

Pair a short-lived stateless access token with a long-lived stateful refresh token, where most designs converge. The access token is good for 5 to 15 minutes and verified locally by every service on your hot path. The refresh token is opaque, stored on your side, and revocable.

See what that arrangement buys. Verification stays free where it runs billions of times, and revocation lives where it runs once per client every few minutes.

Count the state you kept: one row per device grant rather than one per session, touched on refresh instead of on every request.

Rotate the refresh token and you get theft detection almost for free. Each exchange returns a new one and marks the old one used. If a used token ever arrives again, two parties hold copies, and your server revokes the whole family on the spot.

A second hybrid

Meet a second hybrid at your company's edge: opaque outside, signed inside. Public clients hold an opaque token that leaks nothing if it turns up in a log. Your gateway checks it once and forwards a signed token inwards, so internal services keep verifying locally.

Run both models side by side if that fits, which plenty of companies do. Cookie sessions for the server-rendered site, tokens for the public API and the mobile apps, one identity system underneath.

Answer the binary framing by naming the real axis when an interviewer sets it up. Where does your revocation state live, and how often is it consulted? Then place each credential on that axis deliberately.

the shape of it
ClientAPIverifies JWT locallyAuth serviceRefresh tokensrevocable rows1. JWT, 10 min exp2. refresh exchange3. check + rotate4. new JWT
step 1 of 4
The hot path stays stateless while revocation lives in the refresh path, consulted every few minutes instead of every request.

Worked example

Sofia runs authentication at a media startup with about 600,000 monthly users and implements refresh rotation the way Auth0's documentation lays it out: every refresh returns a new token and flags the old one as used. Two months in, an alert fires at 3 am: a used refresh token was replayed from an IP on another continent. A user's tokens had been lifted by a malicious browser extension. Reuse detection revoked the entire token family in under a second, logging out both the attacker and the legitimate user; the user signed back in with their password the next morning and the attacker was left holding dead strings. Without rotation, that stolen refresh token would have quietly minted fresh access tokens for its full 30-day lifetime, and nobody would have had a reason to look.