Authentication Architecture (JWT, Cookies, SSO) — System Design Interview Guide

The Core Approaches

Session-Based (Server-Side Session)

The server creates a session record on login and returns a session ID as a cookie. On every request, the server looks up the session ID. Session state lives on the server (memory, Redis, DB).

// Login — server creates session, sets cookie
POST /login → server creates session { userId, expires }
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict

// Subsequent requests — browser sends cookie automatically
GET /profile
Cookie: sessionId=abc123  // server looks up session in Redis

Pro: instant revocation — delete the session record. Con: requires session store, doesn't scale horizontally without sticky sessions or shared Redis.

JWT — JSON Web Tokens

The server issues a signed token containing claims (userId, roles, expiry). The token is self-verifiable — no database lookup needed. It has three base64-encoded parts: header.payload.signature.

// JWT payload (decoded — NOT encrypted, just base64)
{
  "sub": "user_123",
  "email": "user@example.com",
  "role": "admin",
  "iat": 1700000000,
  "exp": 1700003600  // expires in 1 hour
}
// Signed with a server secret — tampering invalidates the signature

Pro: stateless — works across microservices without a shared session store. Con: cannot revoke individual tokens before expiry without a blocklist (defeating the stateless benefit).

Token Storage — The Critical Question

This is the most common interview question in this area:

• localStorage — simple, persists across tabs. Vulnerable to XSS — any JavaScript on your page can read it: localStorage.getItem('token').
• sessionStorage — cleared on tab close, still XSS-vulnerable.
• httpOnly cookie — JavaScript cannot read it (document.cookie won't show it). Protected from XSS. Must mitigate CSRF separately. This is the recommended storage for access tokens.

// Secure token storage — set by server, httpOnly
Set-Cookie: access_token=<jwt>; HttpOnly; Secure; SameSite=Strict; Path=/

// Client code cannot access it
document.cookie  // won't show access_token
localStorage     // empty — token not stored here

Refresh Token Rotation

Access tokens are short-lived (15 min). Refresh tokens are long-lived (7–30 days) and stored securely (httpOnly cookie). When the access token expires, the client uses the refresh token to get a new one.

// Token refresh flow
1. Access token expires (401 response)
2. Client sends refresh token to /auth/refresh
3. Server validates refresh token, issues new access + new refresh token
4. Old refresh token is invalidated (rotation — prevents token reuse attacks)
5. Client retries original request with new access token

Rotation means each refresh token is single-use. If a stolen token is used, the legitimate user's next refresh attempt fails, alerting the system to a potential breach.

OAuth 2.0 and SSO

OAuth 2.0 is an authorization framework — "Sign in with Google" delegates authentication to a trusted provider. The frontend uses the Authorization Code flow with PKCE (no client secret exposed in browser).

// PKCE Authorization Code Flow
1. Generate code_verifier (random string) + code_challenge (SHA256 hash)
2. Redirect to OAuth provider: /authorize?code_challenge=...&response_type=code
3. User authenticates at provider, redirected back with ?code=...
4. Exchange code + code_verifier for tokens at /token endpoint
// ^ code_verifier proves the same client that started the flow is completing it

SSO (Single Sign-On): one authentication session works across multiple apps. Implemented via shared cookies on the same domain, or via OAuth/SAML with a central identity provider (Auth0, Okta, Cognito).