What is Session Management?
Session management maintains the authenticated state of a user across multiple HTTP requests. HTTP is stateless — without sessions, users would need to re-authenticate on every request. Two primary approaches: server-side sessions (store session data on the server, give the client a session ID) and client-side sessions (store session data in a signed token on the client, e.g., JWT).
Server-Side Sessions (Redis)
# On login:
session_id = generate_secure_random_token(32) # 256-bit
session_data = {'user_id': 123, 'role': 'admin',
'created_at': now(), 'last_active': now()}
redis.setex(f'session:{session_id}', 3600, json.dumps(session_data))
# Set cookie: Set-Cookie: session_id={session_id}; HttpOnly; Secure; SameSite=Strict
# On request:
session_id = request.cookies['session_id']
data = redis.get(f'session:{session_id}')
if not data: redirect_to_login()
session = json.loads(data)
redis.expire(f'session:{session_id}', 3600) # extend TTL on activity
Advantages: instant revocation (delete the Redis key), small cookie payload, session data stays on server. Disadvantages: Redis is in the critical path of every authenticated request; Redis becomes a single point of failure (mitigate with Redis Cluster + read replicas).
JWT (JSON Web Tokens) — Stateless Sessions
# Structure: header.payload.signature (Base64URL encoded)
# Payload:
{
"user_id": 123,
"role": "admin",
"iat": 1620000000, # issued at
"exp": 1620003600, # expires at (1 hour)
"jti": "unique-token-id" # JWT ID for revocation
}
# Signed with HS256 (HMAC-SHA256) using a server-side secret
Advantages: stateless — no server-side storage, scales horizontally. Verifying a JWT requires only the secret key, no DB lookup. Disadvantages: revocation is hard — a JWT is valid until expiry even if the user logs out. Mitigate with a short expiry (15 minutes) + refresh token. Payload is visible (Base64 encoded, not encrypted) — don’t put sensitive data in JWT.
Refresh Token Pattern
Short-lived access token (JWT, 15 min) + long-lived refresh token (opaque token, 30 days). The access token is used for API calls. When it expires, the client sends the refresh token to get a new access token without re-authentication. Refresh tokens are stored server-side (Redis or DB) and can be revoked. On logout: invalidate the refresh token. Rotation: each use of the refresh token issues a new one and invalidates the old — limits the window of refresh token theft.
Concurrent Session Management
Limit concurrent sessions per user (e.g., max 3 devices). Track active sessions: SADD user_sessions:{user_id} {session_id}; store session metadata (device, IP, last_active). On new login: if session count >= max, revoke the oldest session. On logout: SREM user_sessions:{user_id} {session_id}; delete the session key. Admin can revoke all sessions: SMEMBERS user_sessions:{user_id} → delete each session key → delete the set.
Security Hardening
- HttpOnly cookie: prevents JavaScript from reading the session cookie (XSS protection)
- Secure flag: cookie only sent over HTTPS
- SameSite=Strict: prevents CSRF — cookie not sent on cross-site requests
- Session regeneration: after login, generate a new session ID (prevents session fixation attacks)
- IP/User-agent binding (optional): invalidate session if IP or user-agent changes — reduces session hijacking risk, but breaks for mobile users on mobile networks
Key Design Decisions
- Redis sessions for monolith/small services — instant revocation, simple implementation
- JWT for microservices — stateless, no inter-service session lookup
- Short JWT + refresh token — combines stateless benefits with revocation capability
- Always HttpOnly + Secure + SameSite cookies — baseline security
- Session regeneration on privilege change (login, sudo) — prevents session fixation
Google system design covers authentication and session management. See common questions for Google interview: session management and authentication design.
Meta system design covers identity and session management. Review patterns for Meta interview: session management and identity system design.
Apple system design covers security and session management. See design patterns for Apple interview: session management and security design.
See also: Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering
See also: Atlassian Interview Guide