Design an authentication and SSO service

A JWT access token is signed by the auth service; any API can verify it locally with the public key from the JWKS endpoint, so 2M verifications per second cost the auth service nothing. The weakness is revocation: a JWT is valid until exp, even after logout. An opaque token (random string) requires a lookup (introspection) on every call, which is easy to revoke but puts the auth store on every request path. The standard answer is a hybrid. Access tokens are short-lived JWTs (5-15 minutes) and contain only stable claims (sub, aud, scope, tenant, sid), not data that changes often. Refresh tokens are opaque, long-lived (30-90 days with sliding expiry), stored hashed in the database, and checked on every refresh, so logout revokes the refresh token and the access token dies within 15 minutes. For urgent cases (account takeover, employee offboarding) publish a small revocation entry (sid or user_id revoked_after T) via Redis pub/sub to services, which check it in memory; entries expire after 15 minutes because the tokens would have expired anyway. Always validate alg against an allow-list (never accept 'none' or switch RS256 to HS256), and check iss and aud so a token minted for one product cannot be replayed against another.

Mobile apps keep users logged in for months, so the refresh token is the crown jewel. Store it in the Android Keystore / iOS Keychain, never in plain shared preferences; for browsers, keep tokens out of JavaScript where possible (a backend-for-frontend holds them and the browser gets an HttpOnly session cookie). On the server, rotate on every use: each refresh returns a new refresh token and marks the old one used, all linked by a token family id. If a used token comes back, either an attacker or the real client is replaying a copy, so the server revokes the whole family and the user logs in again. Handle the honest race: an app with two parallel requests may refresh twice within a second, or a network failure may drop the response. Allow a short grace window (e.g. 10-30 s) where the previous token returns the same new token, so legitimate retries do not log users out. Store only SHA-256 hashes of tokens so a database leak does not give out sessions, and record device, IP and last-used time so users can see and revoke sessions.

Tokens are signed with an asymmetric key (ES256 is smaller and faster than RS256; EdDSA is also used). The private key lives in KMS/HSM or is encrypted at rest, and only the auth service can use it. Each key has a kid that is placed in the JWT header. Rotation without downtime works in three phases: publish the new public key in JWKS as 'next' (services refresh JWKS every few minutes and cache it), wait longer than the JWKS cache time, then start signing with the new key, and keep the old public key in JWKS until all tokens it signed have expired (15 minutes plus margin). Services should refetch JWKS when they see an unknown kid (with a rate limit to stop attackers forcing refetches). If a key is compromised, remove it from JWKS immediately and accept that every session using it must refresh. Calling KMS for every signature adds latency and cost at 20k tokens/s, so a common pattern is a short-lived signing key generated in memory and certified by the KMS root, or KMS with local caching of data keys.

In India most consumer logins use phone + OTP, so the OTP endpoint is both the front door and a money leak. Attackers trigger millions of OTP sends to premium-rate or random numbers (SMS pumping), costing lakhs per day, or try to brute-force 6-digit codes. Defences: rate limits per phone, per IP, per /24 subnet, per device id and globally per country prefix; CAPTCHA or Play Integrity / App Attest checks before sending; exponential cool-down for resends; at most 5 verify attempts per challenge; and alerts when send volume deviates from normal by hour. Codes are random 6 digits, stored hashed, valid 5 minutes, single use. For passwords, credential stuffing (lists of leaked passwords) is the main threat: hash with Argon2id or bcrypt, check new passwords against breached-password lists, rate-limit per account and per IP with progressive delays, use risk scoring (new device, impossible travel) to require MFA, and return the same error message for 'unknown user' and 'wrong password'. Passkeys (WebAuthn) remove phishing risk entirely and are worth offering.

Security protocols are easy to get subtly wrong (redirect URI matching, PKCE, SAML signature wrapping attacks). Managed providers or Keycloak give certified flows quickly. Building your own makes sense at very large scale, for full control of user experience (OTP flows, regional languages), cost, and data localisation. Many companies run Keycloak or a managed provider for enterprise SSO and their own service for high-volume consumer OTP login.

Short (5 min) gives faster revocation but more refresh traffic and more sensitivity to auth outages. Long (1 hour) cuts load but leaves stolen tokens valid longer. 10-15 minutes plus a fast revocation channel for emergencies is a common balance.

SSO across products works by every product redirecting to the same auth domain, which already has a session cookie, so the user sees no login form. Sharing tokens between apps directly or using third-party cookies breaks with browser privacy changes. On mobile, a shared system browser session or an account manager achieves the same.

If the auth service is down for 20 minutes, almost every access token expires, and on recovery 20M clients refresh at once. Clients should use jittered retries; the service should prioritise refreshes over new logins, and access tokens can carry a slightly randomised TTL so expiries spread out.

At 20k refreshes/s, every refresh writes the session row. Shard sessions by user_id, keep writes minimal (one row update), and cache session lookups in Redis with write-through.

Existing access tokens keep working because verification is local, so most traffic is unaffected for up to the token lifetime. New logins and refreshes fail; apps should keep using cached tokens and retry with backoff. Run the auth service active-active across availability zones and regions, with the users database replicated, because auth is the most critical dependency.

OTP delivery fails. Use two or three SMS providers with health-based routing, a WhatsApp or voice-call fallback, and longer-lived sessions so fewer users need to log in during the outage.

Remove the key from JWKS, sign with a new key, and force all sessions to refresh. Because refresh tokens are opaque and server-side, users stay logged in after one refresh; only tokens signed with the leaked key stop working.