Authentication, OAuth 2.0 & Security Concepts
20 in-depth architectural topics from OAuth 2.0 PKCE and RS256 JWTs to HttpOnly Cookie defenses, RBAC/ABAC engines, and Argon2id password hashing.
OAuth 2.0 Authorization Code Flow with PKCE (Proof Key for Code Exchange)
PKCE eliminates the need for client secrets in public Single Page Apps (React/Next.js) and Mobile Apps. The client generates a random Code Verifier and sends its SHA-256 Code Challenge; the authorization server verifies the hash on token exchange.
JSON Web Tokens (JWT): Header, Payload Claims & RS256 vs HS256
JWTs encode claims into 3 Base64URL-encoded segments separated by dots: Header.Payload.Signature. HS256 uses a symmetric shared secret, while RS256 uses an asymmetric private key to sign and a public key (JWKS) to verify across microservices.
Storage & Transport Security: HttpOnly SameSite Cookies vs Bearer Tokens
Storing JWTs in LocalStorage leaves them vulnerable to instant theft via Cross-Site Scripting (XSS). HttpOnly, Secure, SameSite=Strict cookies cannot be accessed by malicious JavaScript, completely eliminating XSS token exfiltration.
Authorization Engines: Role-Based (RBAC) vs Attribute-Based (ABAC)
RBAC grants permissions based on static user roles (Admin, Editor, Viewer). ABAC (Policy Decision Points) evaluates fine-grained dynamic attributes (User Department, Document Owner ID, IP Geolocation, Working Hours).
Password Hashing: Argon2id vs bcrypt vs PBKDF2 & Salt Hardness
Standard cryptographic hashes (SHA-256, MD5) execute in nanoseconds, making them dangerously susceptible to GPU brute-force attacks. Password hashing functions (Argon2id, bcrypt) are computationally expensive and memory-hard, enforcing unique random salts per user.
OpenID Connect (OIDC): Identity Layer, ID Tokens & JWKS Key Rotation
OIDC is an identity layer built on top of OAuth 2.0. While OAuth 2.0 provides authorization (Access Tokens for API access), OIDC provides authentication (ID Tokens in JWT format containing user identity claims, signed by the IdP).
WebAuthn & FIDO2: Biometric Hardware Passkeys & Phishing Defense
WebAuthn replaces passwords with asymmetric public-key cryptography stored in device hardware Secure Enclaves (TouchID, FaceID, YubiKey). Login challenges are signed by device private keys bound strictly to origin domain names, making credential phishing mathematically impossible.
Time-Based One-Time Passwords (TOTP RFC 6238) & 30s Timesteps
TOTP computes dynamic 6-digit codes by taking a shared Base32 secret key and a 30-second epoch time counter (T = floor(UnixTime / 30)), hashing them with HMAC-SHA1 and performing 4-bit dynamic truncation.
Enterprise Single Sign-On (SSO): SAML 2.0 vs OIDC & XML Signatures
SAML 2.0 exchanges XML-based assertions between an Identity Provider (Okta, Azure AD) and a Service Provider (enterprise SaaS application). Authentication occurs via browser POST/Redirect bindings with XML digital signatures.
JWT Revocation & Blacklisting: Short-Lived Tokens vs Redis Bloom Filters
Stateless JWTs cannot be revoked natively before their exp timestamp. Architectures enforce instant logout via Short-Lived Access Tokens (15 mins) + Refresh Token Rotation with Redis Blacklists or Bloom Filters.
Cross-Site Request Forgery (CSRF): Synchronizer Tokens & SameSite Cookies
CSRF tricks an authenticated user's browser into sending unauthorized POST requests to a vulnerable server. Mitigated via SameSite=Lax/Strict cookie attributes and Synchronizer CSRF Token headers (X-CSRF-Token).
Cross-Site Scripting (XSS) Defenses & Content Security Policy (CSP)
XSS injects malicious JavaScript into trusted web pages (Stored, Reflected, DOM-based). Defenses require strict Context-Aware Output Encoding and Content Security Policy (CSP) headers restricting script-src execution.
Cross-Origin Resource Sharing (CORS): Preflight OPTIONS & Credentials
CORS is a browser security mechanism that restricts cross-origin HTTP requests. Requests with custom headers or non-simple methods trigger an HTTP OPTIONS Preflight request to verify allowed origins, methods, and credentials.
Developer API Keys: Prefixing (sk_live_), SHA-256 Hashed Storage & Scopes
Developer API keys authenticate programmatic machine-to-machine requests. Stripe-style API key design uses human-readable prefixes (sk_live_), high-entropy random bytes, and SHA-256 hashed storage in databases.
Distributed Session Storage: Sticky Sessions vs Redis Clusters
Stateful sessions store user state on the server. Sticky load balancing pins users to single servers (vulnerable to server crashes). Distributed Redis session clusters share session state across all horizontal API nodes.
Mutual TLS (mTLS) & Zero Trust Service-to-Service Authentication
Standard TLS authenticates only the server to the client. Mutual TLS (mTLS) requires both client and server to present and verify X.509 cryptographic certificates issued by a private Certificate Authority (CA), enforcing Zero Trust in microservices.
OAuth 2.0 Scopes, Claims & Principle of Least Privilege
OAuth 2.0 scopes (e.g. read:profile, write:orders) limit the permissions granted to third-party applications. Resource servers inspect token scope claims before executing protected API operations.
Brute-Force & Credential Stuffing Defenses: Account Lockout & CAPTCHA
Credential stuffing uses billions of leaked username/password combinations to breach accounts. Defenses combine Exponential IP Rate Limiting, Account Lockout with email unlock tokens, and Adaptive CAPTCHAs.
HTTP Security Headers: HSTS, X-Content-Type-Options & Permissions-Policy
Security headers instruct browsers to enforce strict transport encryption, prevent MIME-sniffing drive-by downloads, and disable unused device hardware APIs (Camera, Microphone, Geolocation).