Design an authentication service with SSO for multiple apps.

Summary

Run a central identity provider implementing OpenID Connect: apps redirect users to it (Authorization Code + PKCE), it authenticates (passwords with MFA, social or enterprise IdPs), issues short-lived ID/access tokens and refresh tokens, and maintains a central session for single sign-on and logout.

Requirements

• Login once, access many apps
• MFA, social login, enterprise SAML/OIDC federation
• Token-based API access
• Revocation, audit logs, account recovery

API

GET  /authorize?response_type=code&client_id=...&code_challenge=...&redirect_uri=...
POST /token   (code + code_verifier → access_token, id_token, refresh_token)
GET  /.well-known/openid-configuration    GET /jwks.json
POST /logout

Data Model

users(id, email UNIQUE, password_hash /* argon2id */, mfa_secret, status)
sessions(id, user_id, created_at, last_seen, ip, user_agent)
clients(id, redirect_uris, allowed_scopes)
refresh_tokens(id_hash, user_id, client_id, family_id, expires_at, revoked)

Architecture

Apps delegate login to the IdP; the IdP sets its own session cookie so subsequent app logins are silent. Access tokens are signed JWTs verified by APIs using JWKS; refresh tokens rotate with reuse detection. Brute-force protection, risk-based MFA and audit events are built in. Most teams adopt an existing product (Keycloak, Auth0, Cognito, Entra ID) rather than building one.

Deep Dives

• Token lifetimes: short access tokens (5–15 min), rotating refresh tokens
• Logout: front/back-channel logout, revoke sessions
• Key rotation: multiple keys in JWKS with kid

Scaling

• Stateless token verification at APIs
• Session store replicated (Redis/DB)

Comparison / Tradeoffs

What interviewers look for

A structured approach: clarify requirements and scale, sketch the API and data model, draw the high-level architecture, then go deep on the hardest component and discuss trade-offs, bottlenecks and failure modes.

Follow-up questions

• How do you revoke a JWT before it expires?