Session vs Token Authentication: Stateful vs Stateless Identity
Series: System Design · APIs & Communication — Pillar 3 of 8 This pillar: 00 — Overview · 01 — API Design · 02 — REST APIs · 03 — Authentication vs Authorisation · 04 — Session vs Token Auth · 05 — OAuth & OpenID Connect · 06 — JWT · 07 — WebSockets · 08 — Long Polling, SSE & Webhooks · 09 — Sync vs Async Communication · 10 — API Gateways · 11 — Wrap-up
Session vs Token Authentication: Stateful vs Stateless Identity
Systems Design
| # | Post | What it covers |
|---|---|---|
| 00 | APIs & Communication: How Services Talk to Each Other | How services talk to each other shapes everything about a system. Nine concepts covering REST, WebSockets, async patterns, and API gateways. (146 chars) |
| 01 | API Design: Building Contracts That Last | A great API is a contract that outlasts your code. Here are the principles that make APIs intuitive to consume, safe to evolve, and cheap to maintain. (154 chars) |
| 02 | REST APIs: Constraints That Create Benefits | REST isn't just HTTP with JSON. It's an architectural style with specific constraints — and understanding them explains why REST APIs are designed the way they are. (166 chars) |
| 03 | Authentication vs Authorisation: Two Questions, Two Checks | Authentication is who you are. Authorisation is what you're allowed to do. Confusing them is one of the most common security mistakes in system design. (153 chars) |
| 04 | Session vs Token Authentication: Stateful vs Stateless Identity ← you are here | Session auth stores identity on the server. Token auth encodes it in the token. Here's how each works, where each breaks, and how to choose. (144 chars) |
| 05 | OAuth 2.0 & OpenID Connect: Delegated Access and Federated Identity | OAuth 2.0 lets users grant apps access without sharing passwords. OpenID Connect adds identity on top. Here's how both actually work. (137 chars) |
| 06 | JWT: What's Actually Inside the Token | JWTs are everywhere in modern auth — and frequently misused. Here's exactly what a JWT contains, how the signature works, and what it doesn't protect. (153 chars) |
| 07 | WebSockets: Real-Time Bidirectional Communication | HTTP is request-response. WebSockets are a persistent two-way channel. Here's how they work, when to use them, and what to watch out for at scale. (151 chars) |
| 08 | Long Polling, SSE & Webhooks: The Server-Push Spectrum | Three patterns for server-push communication — long polling, server-sent events, and webhooks. Here's how each works and when to reach for each. (150 chars) |
| 09 | Sync vs Async Communication: The Architectural Fork | Synchronous services couple tightly. Asynchronous services decouple — but add complexity. Here's how to reason about which your system needs. (147 chars) |
| 10 | API Gateways: One Entry Point, Every Cross-Cutting Concern | An API gateway centralises auth, rate limiting, routing, and observability for all your services. Here's what it does, how it works, and when you need one. (158 chars) |
| 11 | APIs & Communication: Wrap-Up | A complete recap of all ten API and communication concepts — REST, auth, JWT, WebSockets, webhooks, async patterns, and API gateways — and how they connect. (161 chars) |
Choosing between them
Use session auth when:
- Building a traditional server-rendered web application where cookies are native
- Immediate revocation is a hard requirement (financial services, high-security applications)
- All clients are browsers on the same domain
- Simplicity of implementation is prioritised over horizontal scalability
Use token auth when:
- Supporting mobile clients, SPAs, or third-party API access
- Building for horizontal scale without shared session state
- Operating microservices where multiple services need to validate identity
- Issuing API keys or OAuth tokens to external developers
In the URL shortener platform: the web app uses token auth (SPA calling API — same mechanism as mobile). The mobile app uses token auth (no choice). Third-party API access uses long-lived API keys (a form of token auth). The admin dashboard uses token auth with short access tokens and refresh rotation. Session auth is nowhere — the platform has no traditional server-rendered pages.
The tradeoffs
Security model difference. Session auth's security model is: protect the session store, protect the session ID in transit (HTTPS), rotate session IDs on privilege escalation. Token auth's security model is: protect the signing key, use short expiry, implement refresh rotation, store tokens securely on the client. Both are achievable; the attack surfaces are different.
The XSS vs CSRF tradeoff. Cookies (session auth) are vulnerable to CSRF attacks — a malicious page can cause a browser to send authenticated requests to your API. SameSite cookies mitigate this. localStorage (common for token storage) is vulnerable to XSS — a script injection can steal tokens. Secure, httpOnly, SameSite cookies are the most secure storage even for tokens. The tradeoff is real and neither option is automatically safe.
The one thing to remember
Session auth and token auth are both valid — the choice is about where the state lives and who controls it. Sessions give the server control and instant revocability. Tokens give clients portability and services stateless validation. For modern API-first architectures supporting multiple client types, token auth with short-lived access tokens and revocable refresh tokens is the standard approach. For traditional web applications where revocation matters more than portability, sessions remain entirely appropriate.
← Previous: Authentication vs Authorisation — REST defines the interface structure; the next two concepts define who can use it and what they're allowed to do.
→ Next: OAuth 2.0 & OpenID Connect — token auth handles first-party identity; OAuth handles the case where a user wants to grant a third-party access to their resources without sharing their credentials.
