System Design: Security

Master modern authentication, authorization, OAuth 2.0 / OIDC, SSO, distributed rate limiting algorithms, API security, envelope encryption, DDoS mitigation, and GDPR compliance.

1. Authentication (AuthN) vs Authorization (AuthZ)

Security in distributed architectures begins with two distinct pillars: verifying who a user is (Authentication) and determining what actions they are permitted to execute (Authorization).

Authentication vs Authorization Pipeline & Access Decision Flow

System Design

Tracing credentials verification, 401 Unauthorized handling, Policy Decision Points (PDP), and 403 Forbidden checks

100%
Loading system design canvas…

Authentication (AuthN), 401 Unauthorized

Confirms user identity via Passwords, Time-Based One-Time Passwords (TOTP MFA), Biometrics (WebAuthn/FIDO2), or cryptographic signatures. If identity verification fails, the server responds with HTTP 401 Unauthorized.

  • Password Hashing: Argon2id, bcrypt, PBKDF2 (salted, slow hashes)
  • Multi-Factor Authentication (MFA): TOTP (RFC 6238), SMS, Hardware keys (YubiKey)

Authorization (AuthZ), 403 Forbidden

Evaluates if an authenticated identity has permission to access a target resource. If the user is identified but lacks permissions, the server responds with HTTP 403 Forbidden.

  • RBAC (Role-Based Access Control): Roles assigned permissions (Admin, Editor, Viewer)
  • ABAC (Attribute-Based Access Control): Dynamic policies using user, resource, & environment attributes

2. Session-Based Auth vs Token-Based Auth (JWT)

Architects choose between stateful session IDs stored in centralized caches (like Redis) and stateless signed JSON Web Tokens (JWTs) validated locally on each microservice node.

Session-Based (Stateful) vs JWT Token-Based (Stateless) Architecture

System Design

Comparing Redis session lookups against distributed asymmetric signature validation (RS256)

100%
Loading system design canvas…

JWT Token Security Architecture & Refresh Rotation

JSON Web Tokens consist of three base64url-encoded parts: Header, Payload (Claims), and Cryptographic Signature. Because access tokens are stateless and cannot be easily revoked before expiration, systems use short-lived Access Tokens (15 min) paired with single-use Refresh Tokens (7 days).

  • XSS Mitigation: Store tokens in HttpOnly, Secure, SameSite=Strict cookies rather than localStorage
  • CSRF Mitigation: SameSite cookies + Anti-CSRF double-submit token headers
  • Revocation Strategy: Refresh Token Family rotation with automated token reuse detection

JWT Token Family Rotation & Reuse Compromise Detection in Node.js

A token rotation scheme that tracks refresh token families and revokes them all when reuse is detected.

3. OAuth 2.0 and OpenID Connect (OIDC)

OAuth 2.0 is a delegated authorization framework that allows third-party applications to obtain limited access to an HTTP service on behalf of a resource owner. OpenID Connect (OIDC) extends OAuth 2.0 by adding a standardized identity layer with ID Tokens.

OAuth 2.0 Authorization Code Flow with PKCE (RFC 7636)

System Design

Visualizing client challenge generation, authorization code exchange, and ID Token verification

100%
Rendering diagram…

OAuth 2.0 Core Roles & Grant Types

Delegates resource access without sharing user passwords.

  • Resource Owner: The end-user who grants access
  • Client: The application requesting access (SPA, Mobile, Backend)
  • Authorization Server: Authenticates user and issues tokens (Auth0, Okta)
  • Resource Server: The API backend hosting protected resources
  • PKCE (Proof Key for Code Exchange): Eliminates auth code interception attacks on SPAs

OpenID Connect (OIDC) Identity Layer

Adds authentication on top of OAuth 2.0 authorization.

  • ID Token: A signed JWT containing user identity assertions (sub, email, name, exp)
  • UserInfo Endpoint: Protected REST endpoint returning detailed user profiles
  • Discovery Endpoint: /.well-known/openid-configuration publishing JWKS public keys

4. Single Sign-On (SSO) & Enterprise Identity Federation

Single Sign-On (SSO) allows users to authenticate once with a centralized Identity Provider (IdP) and gain seamless access to multiple independent applications (Service Providers) without re-entering credentials.

Single Sign-On (SSO) Identity Provider Federation Topology

System Design

Centralized identity validation across enterprise SaaS apps with SAML 2.0 & OIDC

100%
Rendering diagram…

SAML 2.0 vs Modern OIDC SSO

Enterprises traditionally use SAML 2.0 (Security Assertion Markup Language) with XML-based assertions signed by X.509 certificates. Modern cloud-native systems standardise on OIDC SSO due to lightweight JSON payloads, native mobile support, and seamless JWT integration.

  • Identity Provider (IdP): Okta, Azure AD (Entra ID), Ping Identity, Google Workspace
  • Service Provider (SP): The application (Slack, Jira, Salesforce, AWS Console)
  • Just-In-Time (JIT) Provisioning: Automatically creates user records in the SP upon first successful SSO login

5. API Rate Limiting Algorithms

Rate limiting defends APIs against denial-of-service, brute-force attacks, web scraping, and cascading failures by restricting the number of requests a client can submit within a timeframe.

Core API Rate Limiting Algorithm Topologies

System Design

Comparing Token Bucket, Leaky Bucket, Fixed Window, and Sliding Window mechanics

100%
Loading system design canvas…

Token Bucket vs Leaky Bucket

Token bucket refills tokens at rate r up to capacity C and allows bursts. Leaky bucket processes requests at a constant outflow rate, buffering bursts in a queue.

  • Token Bucket: Ideal for APIs that allow bursty traffic (AWS API Gateway)
  • Leaky Bucket: Ideal for systems requiring smooth, constant write throughput

Fixed Window vs Sliding Window Counter

Fixed window resets counters at fixed timestamps (risking 2x bursts at boundaries). Sliding window counter blends past and current window weights for accurate throttling.

  • Fixed Window Flaw: 100 reqs at 11:59 + 100 reqs at 12:00 = 200 reqs in 2 seconds!
  • Sliding Window Solution: Smooth rolling calculation across arbitrary 60-second windows

Distributed Sliding Window Rate Limiter (Atomic Redis Lua Script)

System Design

Visualizing ZREMRANGEBYSCORE timestamp pruning and atomic concurrency protection

100%
Rendering diagram…

Distributed Sliding Window Rate Limiter with Atomic Redis Lua Script

A rate limiter that uses an atomic Redis Lua script to enforce a sliding window limit across distributed nodes.

6. API Keys, Secrets Management & Tiered Throttling

API keys authenticate machine-to-machine integrations. Never store raw API keys in plain text; instead, store one-way SHA-256 hashes and use standard HTTP headers to communicate rate limits.

API Key Security Best Practices & Standard Headers

Structure API keys with distinct prefixes (e.g. sk_live_abc123) for automated regex scanning in GitHub leak detection tools. Return RFC 6585 and IETF rate limit headers on every response.

  • X-RateLimit-Limit: Maximum permitted requests in the active window (e.g. 1000)
  • X-RateLimit-Remaining: Number of remaining requests permitted before rejection
  • X-RateLimit-Reset: Unix epoch timestamp when the quota resets
  • HTTP 429 Too Many Requests: Returned when quota is exceeded, paired with Retry-After header
  • Tiered Throttling: Free tier (10 req/min), Pro tier (1,000 req/min), Enterprise tier (100,000 req/min)

7. Encryption at Rest and in Transit (mTLS & Envelope Encryption)

Defense-in-depth requires encrypting data while moving across networks (In Transit) and when stored on persistent disks (At Rest).

Envelope Encryption Pattern (KMS Master Key KEK & Local DEK)

System Design

Decoupling data encryption from HSM hardware limits via two-tiered key hierarchies

100%
Loading system design canvas…

Encryption in Transit (TLS 1.3 & mTLS)

TLS 1.3 secures communication with 1-RTT handshakes and Ephemeral Diffie-Hellman (PFS) so compromised private keys cannot decrypt past recorded sessions.

  • TLS 1.3: Enforces Authenticated Encryption with Associated Data (AEAD) ciphers
  • mTLS (Mutual TLS): Both client and server present X.509 certificates for zero-trust microservice communication

Encryption at Rest & Envelope Encryption

Encrypting massive datasets directly with cloud HSMs is slow and throttled. Envelope encryption solves this by generating local single-use Data Encryption Keys (DEKs).

  • AES-256-GCM: Fast hardware-accelerated symmetric encryption with cryptographic integrity authentication
  • Key Encryption Key (KEK): Stored securely inside KMS/HSM to encrypt and decrypt DEKs

Mutual TLS (mTLS) Zero-Trust Microservice Mesh Flow

System Design

X.509 certificate validation, SPIFFE identity verification, and sidecar proxy encryption

100%
Rendering diagram…

Envelope Encryption with AES-256-GCM & KMS Key Hierarchy in Node.js

An envelope encryption scheme that protects AES-256-GCM data keys under a KMS-managed key hierarchy.

8. DDoS Protection & Web Application Firewalls (WAF)

Distributed Denial of Service (DDoS) attacks attempt to exhaust network bandwidth, connection state tables, or CPU application compute. Mitigation requires multi-layered edge scrubbing.

Multi-Layered DDoS Defense Pipeline (Anycast Edge, Scrubbing & WAF)

System Design

Absorbing volumetric L3/L4 floods at CDN edges and filtering malicious L7 HTTP payloads

100%
Loading system design canvas…

Layer 3 & 4 (Network / Transport Layer) Attacks

Aims to exhaust bandwidth and connection tables.

  • SYN Flood: Overwhelms TCP handshake queues; mitigated by SYN Cookies
  • UDP Amplification: Uses misconfigured DNS/NTP servers to reflect giant payloads
  • Anycast BGP Routing: Distributes attack traffic globally across hundreds of edge POPs

Layer 7 (Application Layer) Attacks & WAF

Aims to exhaust database threads and CPU memory.

  • HTTP Flood & Slowloris: Opens thousands of slow HTTP connections to tie up server sockets
  • Web Application Firewall (WAF): Inspects payloads for SQL Injection, XSS, CSRF, and bots
  • Managed Rules: OWASP Top 10 rule sets, Geo-blocking, and Managed IP reputation lists

9. Data Privacy, Governance & Compliance (GDPR Basics)

Regulatory frameworks like GDPR (General Data Protection Regulation) mandate strict technical controls around Personally Identifiable Information (PII), consent management, and data lifecycle disposal.

PII Tokenization & GDPR Crypto-Shredding Architecture

System Design

Enforcing Right to be Forgotten (Art. 17) across distributed data warehouses and backups via key disposal

100%
Rendering diagram…

GDPR Technical Architecture Tenets

Designing systems compliant with privacy by design and privacy by default.

  • Right to be Forgotten (Art. 17): Users can request full data deletion. Systems use "Crypto-Shredding" (destroying per-user encryption keys) to instantly render data unrecoverable in immutable backups and warehouses
  • Right of Access & Portability (Art. 15/20): Export all user-linked data in structured machine-readable formats (JSON/CSV)
  • Data Minimization (Art. 5): Collect only data strictly necessary for the stated purpose; automatically expire data via TTL policies
  • PII Tokenization Vaults: Replace raw identifiers (SSN, credit card, phone) with opaque surrogate tokens before writing to analytics logs

Knowledge Check

1. What is the primary difference between Authentication (AuthN) and Authorization (AuthZ)?

2. Why is PKCE (Proof Key for Code Exchange) recommended in OAuth 2.0 flows?

3. What flaw exists in the Fixed Window Counter rate limiting algorithm?

4. How does Envelope Encryption protect stored data at scale?

5. What is "Crypto-Shredding" in GDPR compliance?