⚠️ This guide is AI-generated and may contain inaccuracies. Always verify against authoritative sources and real-world documentation.
Home → System Design → OAuth & Authentication

🔐 OAuth & Authentication

Identity and access patterns for distributed systems. OAuth 2.0 authorization code flow, JWT tokens, session management — how to handle "who are you?" and "what can you do?" at scale.

Medium Medium-High Frequency

Architecture Diagram — OAuth Authorization Code Flow

👤 User Resource Owner 🌐 App Client (Spotify) AUTH SERVER Google / Auth0 📂 API Resource Server ① Login with Google ② Redirect to Auth ③ User approves consent ④ Auth code → callback ⑤ Code + client_secret → tokens access_token + refresh_token ⑦ GET /api + Bearer access_token JWT Token Contents sub: user_id exp: 15min (short-lived) scope: email, profile sig: RS256 signed Token Refresh JWT expires (15min) → Use refresh_token → Get new JWT (no re-login)

How It Works

Authentication (AuthN) verifies identity — "who are you?" Authorization (AuthZ) checks permissions — "what can you do?" OAuth 2.0 is a delegation protocol: a user authorizes an app to access their data on a provider, without sharing their password.

OAuth 2.0 Authorization Code Flow (Step by Step)

  1. User clicks "Login with Google" on Spotify → Spotify redirects browser to Google's authorization endpoint.
  2. User logs in to Google (if not already) and sees consent screen: "Spotify wants to access your email and profile."
  3. User approves → Google redirects back to Spotify's callback URL with a one-time authorization_code.
  4. Spotify's backend exchanges the auth code + client_secret for tokens (server-to-server, never exposed to browser).
  5. Google returns: access_token (1h TTL), refresh_token (long-lived), id_token (JWT with user info).
  6. Spotify issues its own JWT (15min) + refresh token → subsequent API calls use Spotify's token, not Google's.

Authentication Approaches

JWT (Stateless)

Token contains claims, signed by server. Client sends JWT with each request. No session lookup needed — verify signature locally. But: can't revoke until expiry. Use short-lived (15min) + refresh tokens.

Session-Based (Stateful)

Server stores session in Redis/memory, sends session ID as cookie. Easily revocable (delete session). But: requires shared state across servers. Better for traditional web apps.

Key Distinction: OAuth vs OIDC

OAuth 2.0 is authorization ("Spotify can read my Google profile") — it doesn't authenticate the user. OpenID Connect (OIDC) adds authentication on top ("this is really user@gmail.com"). Most candidates confuse them — knowing the difference shows depth.

Key Design Decisions

⏱️

JWT expiry length: Short (5-15 min) = more refresh calls but faster revocation on password change. Long (1-24h) = fewer refreshes but compromised tokens stay valid for hours. Best practice: 15-minute JWT + refresh token rotation + blacklist for emergency revocation.

🔑

Symmetric vs asymmetric signing: HS256 (symmetric) — one shared secret, simpler but every service needs the secret. RS256 (asymmetric) — private key signs, public key verifies. Microservices should use RS256 so services can verify tokens without holding the signing key.

🔄

Stateless JWT vs stateful sessions: JWT scales horizontally (no shared state) but can't be revoked mid-flight. Sessions are revocable but need shared storage (Redis). Most production systems use both: JWT for API auth, sessions for web app auth.

📱

PKCE for mobile/SPA: Mobile apps can't store client_secret securely. PKCE (Proof Key for Code Exchange) replaces the secret with a dynamic challenge — the modern best practice for public clients.

When to Use

Auth patterns appear in nearly every system design interview. Show you understand the full picture, not just "use JWT."

  • "How do users log in?" — OAuth 2.0 + OIDC for social login, email/password + bcrypt for direct auth
  • "How do microservices authenticate with each other?" — mTLS for service identity, service tokens (JWT) for authorization
  • "How does the mobile app stay logged in?" — Refresh token rotation with short-lived JWTs
  • "How do you implement SSO across multiple apps?" — OIDC with a central identity provider

Interview signal: Walk through the authorization code flow step by step — draw the three parties (user, app, auth server) and the redirect dance. Mention PKCE for mobile apps unprompted.

Real-World Examples

  • Spotify + Google — When you "Continue with Google," Spotify uses the OAuth authorization code flow. Spotify validates the id_token (JWT), extracts email/name, finds or creates a Spotify account, then issues its own JWT + refresh token.
  • Auth0 / Okta — Most SaaS applications delegate authentication entirely to Auth0/Okta. They implement the full OAuth 2.0 + OIDC flow, issue JWTs, and handle token refresh.
  • Kubernetes — Every pod gets a service account token (JWT-like) mounted at /var/run/secrets. Inter-service auth uses these tokens + RBAC policies.
  • GitHub API — Uses OAuth 2.0 for third-party app access. Personal access tokens for CLI. Fine-grained permissions per token.

Back-of-Envelope Numbers

Metric Value
JWT signature verification<1 ms (local, no network)
Recommended JWT expiry5–15 minutes
Refresh token lifetime30–90 days (with rotation)
bcrypt password hash time~100–300 ms (tunable)
Redis session lookup~0.5 ms
Token storage per user (Redis)~200 bytes
240M social auth users × 4 sessions/day~1B token refreshes/day
240M tokens × 200 bytes in Redis~48 GB (2 Redis nodes)