LESSON 29.1
Authentication sessions, JWT and OAuth
Verifying user identity at scale with stateful server-side sessions, stateless JSON Web Tokens, refresh token rotation, and delegated authentication via OAuth and OpenID Connect.
5 min read
Authentication establishes who a user or client is. In a system design interview, selecting an authentication model dictates database write loads, caching patterns, edge termination, and security boundaries.
Production architectures typically choose between two primary paradigms: stateful server-side sessions and stateless signed tokens.
Stateful sessions vs stateless tokens
Server-Side Sessions
- Instant revocation (deleting the session from Redis immediately logs the user out)
- Payload size is tiny (a single 32-byte opaque session cookie)
- Sensitive user attributes are never exposed to the client
- Requires a centralized stateful store (like Redis)
- Every API request incurs a network lookup to validate the session ID
Pick it when: Standard consumer web applications, banking, internal administrative tools.
Stateless JWTs
- Zero database lookups (microservices verify the cryptographic signature locally)
- Naturally cross-domain and mobile-friendly
- Carries user claims directly inside the token payload
- Immediate revocation is difficult
- Token payload increases request header overhead (several KB)
- Secret key leaks compromise all issued tokens
Pick it when: High-throughput microservices, public third-party APIs, mobile apps.
The hybrid pattern: Short-lived access tokens with refresh tokens
To combine the scalability of stateless tokens with the instant revocation of stateful sessions, modern distributed systems implement refresh token rotation:
- Authentication: User submits credentials to
POST /auth/login. - Dual-token issuance: The authentication service returns two tokens:
- Access Token (JWT): Short lifetime (10 to 15 minutes). Carries user ID, permissions, and cryptographic signature. Validated locally by microservices without database queries.
- Refresh Token (Opaque UUID): Long lifetime (14 to 30 days). Stored in a secure
httpOnly,Secure,SameSite=Strictcookie and recorded in a stateful database.
- API access: Client sends the access token in the
Authorization: Bearer <jwt>header on every request. - Token refresh: When the access token expires, the client calls
POST /auth/refresh. The auth server checks the database, validates the refresh token, revokes it, and issues a brand-new access and refresh token pair (Refresh Token Rotation). If a stolen refresh token is used twice, the server detects token reuse and revokes all active sessions for that account.
Delegated authentication: OAuth 2.0 and OpenID Connect
When applications allow users to "Log in with Google" or grant a third-party app permission to read calendar events, they implement OAuth 2.0 and OpenID Connect (OIDC):
- OAuth 2.0: An authorization framework. An authorization server issues an
access_tokenthat grants limited scopes to a resource server (e.g.read:calendar). - OpenID Connect (OIDC): An identity layer built on top of OAuth 2.0. In addition to the access token, the identity provider returns an
id_token(a signed JWT) containing standardized profile claims (sub,email,name,email_verified). - PKCE (Proof Key for Code Exchange): Mandatory security extension for single-page applications and mobile apps to prevent authorization code interception attacks.
Try it
Authentication Session Service HLD
Design a distributed session management service that handles millions of active concurrent users with instant revocation.