Lesson 18 — Designing a Scalable Authentication System

1. What is Authentication & Why is it the Bedrock of System Design?

Throughout this course, we designed large-scale systems: URL Shorteners, Real-Time Chat, Social Media Feeds, Video Streaming Platforms, and Distributed Notification Engines.

Each system solved intricate operational challenges. Yet, in front of virtually every modern web and mobile application sits an unavoidable architectural gatekeeper:

“Who is this user, and can we mathematically trust their claims?”

A user enters their credentials. How does the system verify their identity? The user closes their laptop and reopens the website an hour later—how does the application know they are still authenticated?

Now amplify the complexity:

• The same user is simultaneously active on an iPhone, an Android tablet, and a work laptop.
• Their laptop is stolen in a coffee shop; they take out their phone and press: “Log out of all other devices.”
• The platform serves 100 million registered users, processing 100,000 logins/second and 10 million token verifications/second across global regions.

Simply put: Authentication (AuthN) is the computational verification of an entity's claimed identity. It is the perimeter fence of your entire architecture. If this layer fails, all database encryption and business logic downstream become completely irrelevant.

2. Authentication vs. Authorization: Core Boundaries

One of the most frequent confusions in system design interviews and architectural audits is conflating authentication with authorization:

3. Functional & Non-Functional Requirements

Functional Requirements

• User Registration & Onboarding: Secure input validation and slow cryptographic password hashing.
• Login & Session Establishment: Credential verification and issuance of stateful sessions or stateless token pairs.
• Multi-Device Session Tracking: Storing active device records and providing user-facing device session management.
• Instant Logout & Remote Revocation: Local device logout and atomic invalidation of all remote active sessions.
• Cryptographic Password Reset: Single-use, time-limited cryptographic reset tokens with generic anti-enumeration responses.
• Multi-Factor Authentication (MFA): TOTP (RFC 6238) authenticator app codes or SMS OTP verification challenges.
• Federated Social Identity (SSO): Third-party OAuth 2.0 and OpenID Connect (OIDC) login via Google, Apple, or GitHub.

Non-Functional Requirements

• Zero Credential Compromise: Stored passwords must remain mathematically irrecoverable even if the raw database is leaked (Argon2id/bcrypt).
• High Availability (99.999%): If the authentication system fails, the entire application becomes inaccessible. Multi-region redundancy is mandatory.
• Ultra-Low Verification Latency: Token verification on incoming API requests must take sub-milliseconds (< 1ms) without querying a centralized bottleneck.
• Massive Scalability: Supporting 100M+ registered users, 100,000 logins/second, and 10 million API token verifications/second.
• Anti-Abuse & Denial-of-Service Defense: Thwarting brute-force scripts, automated credential stuffing, and account lockout attacks.

4. Registration Flow & Password Hashing Architecture

The cardinal rule of identity engineering is absolute:

If an attacker acquires a database snapshot via SQL injection, backup exposure, or an insider breach, plaintext passwords result in an immediate, catastrophic corporate failure. Moreover, standard fast cryptographic hashes like MD5, SHA-1, or SHA-256 are fatal for passwords: modern consumer GPUs can compute billions of SHA-256 hashes per second, cracking average passwords via rainbow tables in seconds.

Slow & Memory-Hard Key Derivation Functions (KDF)

Production authentication systems enforce computationally expensive, memory-hard algorithms specifically engineered to neutralize parallel GPU/ASIC attacks:

The Essential Roles of Salt and Pepper

• Cryptographic Salt: A cryptographically secure random string (minimum 16 bytes) generated per user and concatenated with the password prior to hashing. Even if Alice and Bob choose the identical password Password123, their resulting database hashes are completely different. This completely neutralizes precomputed rainbow table attacks.
• Pepper (Secret Key): An application-wide secret key stored outside the database, typically in a Hardware Security Module (HSM) or secret vault (AWS KMS, HashiCorp Vault). The pepper is combined during hash calculation. Even if an attacker steals the complete SQL database dump, they cannot verify or crack passwords without the pepper.

5. Stateful Session-Based Authentication

The classic, time-tested mechanism for server-rendered web applications is Session-based Authentication:

Three Mandatory Cookie Security Flags

• HttpOnly: Prevents client-side scripts from accessing document.cookie. If an XSS vulnerability exists in your application, attackers cannot exfiltrate the session cookie.
• Secure: Instructs the browser to transmit the cookie strictly over encrypted TLS/HTTPS connections, preventing cleartext network sniffing.
• SameSite=Lax / Strict: Instructs the browser not to send the cookie on cross-site requests, mitigating Cross-Site Request Forgery (CSRF) attacks.

Session Scaling & Centralized Redis Clusters

When 10 application servers sit behind a load balancer, storing sessions in local server RAM fails because consecutive requests routed to different servers trigger premature logouts. While Sticky Sessions can bind users to specific servers, they hinder auto-scaling and cause session drops on server restarts.

The standard architectural solution: A centralized, distributed in-memory datastore (such as a Redis Cluster). All application servers perform sub-millisecond lookups against this shared session pool.

6. Stateless Token-Based Authentication (JWT)

In distributed microservice architectures or mobile clients, executing a network lookup against a central Redis cluster for every API call can create performance bottlenecks. The primary alternative is JSON Web Tokens (JWT).

The Three Anatomy Components of a JWT:

1. Header: Metadata specifying the algorithm (alg: RS256) and token type (typ: JWT).
2. Payload (Claims): Identity assertions (sub: user_id, role: admin, exp: 1717000000, iss: auth.byteion.com).
3. Signature: Cryptographic digital signature verifying header and payload integrity.

HS256 (Symmetric) vs. RS256 / EdDSA (Asymmetric)

In microservice environments, avoid symmetric HS256 signing: both the Auth service and downstream consumer services must share the identical secret key. If a single downstream service is compromised, attackers can forge valid authentication tokens for the entire ecosystem.

The standard architectural pattern: Asymmetric Signing (RS256 or Ed25519). The Auth Service holds the Private Key to sign tokens, while all downstream services cache the Public Key (fetched via a /.well-known/jwks.json endpoint). Downstream services verify signatures locally in CPU with zero central network calls and zero ability to forge tokens.

7. Access Token & Refresh Token Lifecycle (RTR Architecture)

If a JWT has a 30-day expiration, and the user's phone is stolen 10 minutes later, the thief retains access for the remaining 30 days because stateless tokens are self-contained and require no database verification.

Solution: Dual-Token Architecture with Refresh Token Rotation (RTR).

Refresh Token Rotation (RTR) & Automated Theft Detection

Whenever the client presents a refresh token (say RT-1) to obtain a new access token, the Auth Server immediately invalidates RT-1 and issues a fresh pair (AT-2 + RT-2).

8. Stateful Sessions vs. Stateless JWT: Architectural Trade-Off Matrix

9. Multi-Device Login & Instant Session Revocation

In production systems, users expect seamless multi-device access alongside granular security controls:

Database Schema Design:

Executing “Log Out All Other Devices”

When Alice initiates a remote logout from her mobile device, the backend executes an atomic operation:

In JWT architectures, the most elegant design is embedding a token_version claim. When Alice logs out of other devices, the server increments token_version on her user record. Downstream gateways checking cached user versions reject any token bearing an older version with an immediate 401 Unauthorized!

10. Password Reset Flow & Abuse Prevention

Password reset endpoints are prime targets for automated account takeover attacks:

Four Golden Rules for Secure Password Resets:

1. Never Store Raw Reset Tokens in the Database: Dispatch the raw_token in the email link, but store only SHA-256(raw_token) in the database. If the database leaks, an attacker cannot forge reset links.
2. Short TTL & Single Use: Enforce strict expiration (10 to 15 minutes), and atomically burn the token upon submission.
3. Generic Responses (Anti-Enumeration): Regardless of whether the submitted email exists in your system, return the identical message: “If an account exists with this email, reset instructions have been sent.” This prevents adversaries from enumerating registered corporate accounts.
4. Global Session Revocation: A successful password reset must immediately invalidate all existing active sessions and refresh tokens across all devices.

11. Brute-Force, Credential Stuffing & Adaptive Security

Adversaries utilize distributed botnets to test credential combinations at scale.

Is Permanent Account Lockout Safe? (A Dangerous Trap)

A common architectural flaw is implementing hard lockouts: “Lock the account permanently after 5 consecutive failures!”

Adaptive Defense & Progressive Throttling

Instead of permanent account lockout, modern systems implement layered progressive friction:

• Progressive Delay (Exponential Backoff): Delays increase exponentially with failed attempts: 0ms for attempts 1-3, 1000ms for attempt 4, 3000ms for attempt 5, 10,000ms for attempt 6. This neutralizes bot script velocity without locking users out.
• Dual-Key Rate Limiting: Enforce limits per IP (e.g., max 10 requests/min) and per account email (max 5 attempts/min) using Redis sliding window counters.
• Step-Up CAPTCHA: Trigger invisible challenges (Cloudflare Turnstile or reCAPTCHA v3) only when risk anomalies occur.
• Step-Up MFA Enforcement: After repeated failures, require secondary authentication (SMS/Email OTP or hardware key) before accepting the password.
• Breached Credential Auditing: Integrate with HaveIBeenPwned API via k-anonymity SHA-1 hash prefixes during registration to reject compromised passwords.

12. Multi-Factor Authentication (MFA) & Modern Identity

Passwords alone are insufficient for modern security postures. MFA combines multiple authentication factors:

SMS OTP vs. TOTP Authenticator: SMS OTP is vulnerable to SS7 protocol interception and SIM swapping attacks. In contrast, TOTP (RFC 6238) runs entirely offline: the client app hashes the current Unix epoch timestamp with a shared cryptographic secret, yielding a dynamic 6-digit code refreshed every 30 seconds. For enterprise-grade protection, FIDO2 / WebAuthn (Passkeys) utilizes hardware-backed asymmetric public-key cryptography directly in the browser, completely immune to phishing.

13. Federated Identity, OAuth 2.0 & OpenID Connect (OIDC)

When users select “Continue with Google”, they do not share their Google password with your application:

• OAuth 2.0: An Authorization Framework designed to grant third-party applications scoped access to user resources (e.g., “Read contacts”).
• OpenID Connect (OIDC): An identity layer engineered on top of OAuth 2.0. It returns a cryptographically signed id_token (JWT) containing verified identity claims (name, email, sub).
• Single Sign-On (SSO): In enterprise environments, employees authenticate once against an identity provider (Okta, Azure AD, Ping) to access hundreds of corporate applications without maintaining separate credentials.

14. Microservices & Service-to-Service Authentication

Authentication is not limited to human users. When the Order Service calls the Payment Service, how does the Payment Service confirm the request originated from an authorized internal service rather than an intruder?

15. Scaling to 100 Million Users: Distributed Auth Architecture

Consider an application with 100 million registered users operating at peak throughput:

• Login Requests: 100,000 logins/second (Write-heavy: Argon2 verification, session generation).
• API Token Verifications: 10,000,000 requests/second (Read-heavy: every page view and data mutation).

Three Foundational Architectural Strategies:

1. Edge-Level Local Token Verification: Routing 10M requests to a central database or cache creates an immediate bottleneck. API Gateways and Cloudflare Edge Workers cache public signing keys (JWKS) and verify asymmetric RS256 signatures in microsecond CPU cycles without central I/O.
2. Partitioned Database Sharding: The primary user database is horizontally sharded by user_id or a consistent hash of the email address, paired with distributed read replicas.
3. Multi-Region Active-Active Replication & Clock Skew: Independent authentication clusters operate across North America, Europe, and Asia. To accommodate server clock drift across distributed datacenters, token expiration logic includes a 30 to 60-second Clock Skew Tolerance.

16. End-to-End Authentication Architecture Diagram

19. Core Takeaways & Master Architecture Mental Model

The core engineering challenge of authentication is never merely: “Is this password correct?” An enterprise identity architecture reasons through the complete lifecycle:

From this point forward, whenever you encounter authentication in a system design interview or production system, you will see beyond a basic “/login” handler. You will see a resilient synthesis of cryptography, distributed cache topology, threat modeling, and fault tolerance.