It's worth stepping back and comparing token-based auth (JWTs) against the older, still extremely common server-side session model directly, because interview questions often frame this as "which is better" when the honest answer is "different trade-offs for different architectures."
| Server-side session | JWT / token-based | |
|---|---|---|
| Where state lives | Server (database, Redis) — cookie holds only an opaque ID | Entirely in the token itself — server verifies, doesn't look anything up |
| Revocation | Instant — delete the session record | Hard — valid until exp, absent extra infrastructure |
| Scaling across servers | Needs a shared session store (Redis, sticky sessions) | Naturally stateless — any server with the verification key can validate it |
| Payload size on the wire | Small (just an opaque ID) | Larger — the full payload travels with every request |
| Best fit | A single application with its own login | Multiple services/APIs needing to verify identity without a shared database |
Neither model is a strict upgrade over the other — a JWT's biggest practical advantage (statelessness, no database hit to verify a request) is also the direct source of its biggest practical weakness (no instant revocation), and plenty of production systems land on a hybrid: a short-lived stateless JWT for API calls, backed by a server-side, instantly-revocable session or refresh token controlling whether new ones keep getting issued.