# 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](/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](/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-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-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-20-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](/jwt-whats-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](/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](/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](/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](/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](/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](/authentication-vs-authorisation-two-questions-two-checks)** — 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](/oauth-20-openid-connect-delegated-access-and-federated-identity)** — 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.*