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 DesignTracing credentials verification, 401 Unauthorized handling, Policy Decision Points (PDP), and 403 Forbidden checks
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 DesignComparing Redis session lookups against distributed asymmetric signature validation (RS256)
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.
Press Run to execute the code and see output here.
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 DesignVisualizing client challenge generation, authorization code exchange, and ID Token verification
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 DesignCentralized identity validation across enterprise SaaS apps with SAML 2.0 & OIDC
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 DesignComparing Token Bucket, Leaky Bucket, Fixed Window, and Sliding Window mechanics
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 DesignVisualizing ZREMRANGEBYSCORE timestamp pruning and atomic concurrency protection
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.
Press Run to execute the code and see output here.
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 DesignDecoupling data encryption from HSM hardware limits via two-tiered key hierarchies
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 DesignX.509 certificate validation, SPIFFE identity verification, and sidecar proxy encryption
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.
Press Run to execute the code and see output here.
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 DesignAbsorbing volumetric L3/L4 floods at CDN edges and filtering malicious L7 HTTP payloads
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 DesignEnforcing Right to be Forgotten (Art. 17) across distributed data warehouses and backups via key disposal
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?