stateful vs stateless authentication: how each approach works
stateful session auth, stateless token auth, server memory vs client storage, scalability tradeoff, cookie vs header, JWT overview
Stateful vs Stateless Authentication
Every auth system falls into one of two categories: stateful or stateless. The difference is where session data lives.
Stateful auth stores session data on the server. When a user logs in, the server creates a session object (user ID, roles, expiry) and saves it — in memory, Redis, or a database. The server sends the client a session ID (usually via a cookie). On each request, the server looks up that session ID to reconstruct who the user is.
Stateless auth embeds all session data inside a token sent to the client. The server does not store anything. On each request, the client sends the token, and the server validates it cryptographically. JWT is the most common stateless format.
The core tradeoff:
- Stateful: Easy to revoke (delete the session), but requires a shared session store across servers — adds infrastructure complexity at scale.
- Stateless: No server storage needed, scales horizontally for free, but tokens cannot be easily invalidated before expiry without a blocklist (which reintroduces state).
Neither is universally better. Traditional web apps often use sessions. APIs and microservices lean toward JWTs. Many production systems use both — short-lived JWTs plus a refresh token stored server-side.