Design an Authentication System
Design an authentication system with JWT vs sessions, OAuth2 flows, password hashing (bcrypt/argon2), MFA, and token refresh.
Quick answer: Design an Authentication System
Design an Authentication System is covered here as a practical system design interview problem. Design an authentication system with JWT vs sessions, OAuth2 flows, password hashing (bcrypt/argon2), MFA, and token refresh. Use it to practice requirements, APIs, storage choices, scaling bottlenecks, data consistency, observability, and failure handling for a easy interview round.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
Problem Statement
Design a centralized authentication and authorization system that handles user registration, login, token management, OAuth2 social logins, and multi-factor authentication (MFA). The system must be secure against common attacks (brute force, credential stuffing, token theft) while maintaining low-latency auth checks for every API request.
Requirements
Functional
- User registration with email/password and email verification
- Login with password (bcrypt/argon2-hashed), returning JWT access + refresh tokens
- OAuth2 social login (Google, GitHub, Apple) using Authorization Code flow
- Multi-factor authentication (TOTP via authenticator app, SMS fallback)
Non-Functional
- Security: Passwords hashed with Argon2id (memory-hard), tokens signed with RS256
- Latency: Token validation <5ms (stateless JWT), login <500ms
- Availability: 99.99% -- auth downtime blocks all services
- Scale: 100M users, 50K logins/second at peak
Core Architecture
-
Auth API Service -- Handles registration, login, and token endpoints. Validates credentials against the user store, issues JWTs (short-lived access token: 15 min, long-lived refresh token: 7 days). Implements rate limiting per IP and per account to block brute force.
-
Token Service -- Issues and validates JWTs signed with RS256 asymmetric keys. Public keys are published at /.well-known/jwks.json so all downstream services can validate tokens without calling the auth service. Supports token revocation via a short-lived blacklist in Redis.
-
OAuth2 Gateway -- Implements Authorization Code flow with PKCE for social logins. Exchanges authorization codes for provider tokens, maps provider user IDs to internal accounts (creating accounts on first login). Stores provider refresh tokens encrypted at rest.
- MFA Service -- Generates TOTP secrets (stored encrypted), validates 6-digit codes with a 30-second window and one-step tolerance. For SMS fallback, integrates with Twilio with rate limiting (max 5 SMS/hour per account). Recovery codes are pre-generated and bcrypt-hashed.
Database Choice
PostgreSQL for the user table (email, password_hash, mfa_secret_encrypted, created_at, locked_until). Relational integrity for OAuth provider linkage (users-to-providers many-to-many). Redis for two critical uses: (1) refresh token whitelist with TTL matching token expiry, enabling instant revocation; (2) rate limiting counters using INCR with TTL (sliding window). Both are small, high-throughput workloads ideal for Redis.
Key API Endpoints
POST /api/v1/auth/register
-> Body: \{ email: "user@example.com", password: "...", name: "Jane" \}
POST /api/v1/auth/login
-> Body: \{ email: "user@example.com", password: "...", mfa_code?: "123456" \}
-> Returns: \{ access_token: "eyJ...", refresh_token: "...", expires_in: 900 \}
POST /api/v1/auth/refresh
-> Body: \{ refresh_token: "..." \}
-> Returns: \{ access_token: "eyJ...", expires_in: 900 \}
Scaling Insight
JWT validation is stateless and decentralized -- the critical scaling property. Every microservice validates tokens locally by checking the RS256 signature against the cached public key. No network call to the auth service is needed for 99.9% of requests. The only centralized check is the Redis revocation blacklist, which holds only recently-revoked tokens (max 15-min TTL) and stays small.
Key Tradeoffs
| Decision | Option A | Option B | Chosen |
|---|---|---|---|
| Token format | Stateless JWT | Server-side sessions | JWT -- eliminates session store bottleneck, scales horizontally |
| Hashing | bcrypt (proven) | Argon2id (memory-hard) | Argon2id -- better resistance to GPU attacks, tunable memory cost |
| Token revocation | Blacklist in Redis | Short expiry + no revocation | Blacklist -- small overhead, but enables instant logout for compromised accounts |
Original DosiBridge notes for Design an Authentication System
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design an Authentication System is to connect the concept to a trust boundary where convenience must not weaken identity, confidentiality, or auditability. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Core Entity: For Design an Authentication System, decide the core entity before choosing tools; otherwise the design looks clean but fails when authentication changes.
- Read/Write Path: For Design an Authentication System, decide the read/write path before choosing tools; otherwise the design looks clean but fails when system changes.
- Contention Point: For Design an Authentication System, decide the contention point before choosing tools; otherwise the design looks clean but fails when authentication changes.
- Abuse Path: For Design an Authentication System, decide the abuse path before choosing tools; otherwise the design looks clean but fails when system changes.
- Recovery Workflow: For Design an Authentication System, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when authentication changes.
Design an Authentication System correctness boundary
For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.
Design an Authentication System scaling bottleneck
The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.
Production review question
If Design an Authentication System suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?
Practical metric to track
Track authentication-system health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design an Authentication System, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.