System Design Chapter 14

Authentication Strategies: Basic, Digest & API Keys

Authentication vs. Authorization, 5 Common Confusions, HTTP Basic, Digest Challenge-Response, & API Keys

★ Auth is 'Who are you?' — never confuse tokens (JWT) or delegation (OAuth 2) with core authentication!

1 What is Authentication? (AuthN vs. AuthZ)

“

Authentication (AuthN) answers 'Who is the user?' whereas Authorization (AuthZ) answers 'What is this user allowed to do?'

— System Design Axiom

🔐 The Fundamental Authentication Decision Flow

📥 Login Request (Credentials / Token)

⬇️

❓Who is the user?

Verify Identity against Stored Hash / Credential Secret

❌If Invalid / Unverified

Reject with HTTP Status

401 Unauthorized+ WWW-Authenticate Challenge Header

✅If Valid & Verified

Establish Session / State

200 OK / Issue SessionSet-Cookie or Return Bearer JWT Token

2 Where Software Engineers Get Confused (5 Pitfalls)

System design interviews frequently expose critical misunderstandings around authentication mechanisms. Here are the 5 foundational confusions disambiguated:

1. AuthN vs. AuthZ Frameworks

Confusion: Conflating identity verification with permissions.
Reality: Authentication proves identity (“Who are you?”). Authorization evaluates scopes & privileges (RBAC, ABAC, ACLs).

2. Treating JWT as an Auth Type

Confusion: Saying “We use JWT authentication”.
Reality: JWT is an open standard token format/carrier (RFC 7519), not an authentication mechanism itself. It simply carries claims.

3. Confusing Bearer Auth & JWT

Confusion: Treating Bearer tokens and JWTs as synonymous.
Reality: Bearer is the HTTP Authorization transport scheme. A JWT is one specific structured payload carried inside the header.

4. Calling OAuth 2 an Auth Method

Confusion: Claiming OAuth 2 is a login system.
Reality: OAuth 2 is a delegated authorization protocol. OpenID Connect (OIDC) is the identity layer on top that provides true authentication.

5. Mixing Up SSO with Auth Protocols

Confusion: Viewing Single Sign-On as an isolated protocol.
Reality: Single Sign-On (SSO) is an identity management architectural pattern orchestrated via protocols like SAML 2.0 or OIDC.

HTTP Basic Authentication Flow (RFC 7617)

The earliest and simplest HTTP authentication scheme. The client transmits credentials inside the Authorization header using reversible Base64 encoding.

🪜 Basic Authentication: Interactive Multi-Lane Message Flow

📱 Client / Browser

HTTP Request / Response Cycle

🖥️ Web Server / Proxy

① Client ➔ ServerInitial Request

GET /api/v1/protected/users HTTP/1.1(No credentials provided)

Server ➔ Client ②401 Challenge

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=“Internal Admin Area”

🔐 ③ Browser Modal: Native prompt asks user for username & password ➔ Encodes to Base64

④ Client ➔ ServerBase64 Credentials

GET /api/v1/protected/users HTTP/1.1
Authorization: Basic YWRtaW46c2VjcmV0MTIz(base64(“admin:secret123”))

Server ➔ Client ⑤Authenticated 200

HTTP/1.1 200 OK
Payload returned; browser caches credentials for subsequent calls

⚠️ Major Security Flaws of Basic Auth:

Base64 is NOT Encryption: Base64 is a purely bidirectional encoding algorithm. Anyone intercepting the header can execute atob(“YWRtaW46c2VjcmV0MTIz”) in 1 millisecond.
Mandatory TLS: Basic Auth over unencrypted HTTP exposes credentials directly to packet sniffers on shared Wi-Fi.
Credential Resending: Browsers store the decoded credential pair in memory and automatically attach the header on every single subsequent request.
No Fine-Grained Expiry: Cannot expire or revoke individual tokens without resetting the user’s primary password.

4 2. HTTP Digest Authentication Flow (RFC 7616)

Digest Authentication was engineered to avoid transmitting plaintext passwords across the network through a Challenge-Response Nonce Hashing Scheme:

🛡️ Digest Challenge-Response Multi-Lane Sequence

📱 Client App

Cryptographic Nonce Exchange

🖥️ Origin Server

① Client ➔ ServerInitial GET

GET /api/v1/accounts HTTP/1.1

Server ➔ Client ②401 + Nonce Challenge

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm=“users@site.com”, nonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093”, qop=“auth”

⚙️③ Client Cryptographic Computation (Password Never Sent):

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:nc:cnonce:qop:HA2)

④ Client ➔ ServerComputed Digest

GET /api/v1/accounts HTTP/1.1

Authorization: Digest username=“Mufasa”, realm=“users@site.com”, nonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093”, uri=“/api/v1/accounts”, response=“6629fae49393a05397450978507c4ef1”

Server ➔ Client ⑤Hash Matched (200)

HTTP/1.1 200 OK
Server computes identical hash on backend; grants access

✅ Pros vs. Basic Auth

Zero Plaintext Password Exposure: Passwords stay on the client. Server nonces provide robust protection against basic replay attacks.

⚠️ Modern Deprecation

MD5 Weaknesses: Vulnerable to collision attacks and MITM downgrade attacks. Superseded everywhere by HTTPS + JWT / Bearer tokens.

5 3. API Key Authentication Architecture

The standard pattern for Machine-to-Machine (M2M) communication, developer portals, external billing gateways, and third-party SaaS integrations:

🔑 API Key Verification Architecture & M2M Flow

📱

Client / Third-Party

Holds API Secret Key

🌐

API Gateway

Hashes Key & Rate Limits

🗄️

Redis / Key Store

SHA-256 Hashed Keys + Scopes

① Client transmits request with API Key header:

Authorization: Bearer sk_live_51Msz92kx8921a…(or X-API-Key: sk_live_…)

② Gateway hashes incoming key & looks up in fast cache:

SHA256(raw_key) is matched against Redis / Key-Value DB to retrieve Tenant ID, allowed scopes, & rate limiter tier.

③ Rate Limiting & Scope Verification:

Gateway checks token bucket (e.g. 100 req/min for Tier 1) and validates if key has permission for the requested route (e.g. write:orders).

④ Downstream proxy & 200 OK Response:

Request routed to microservice with injected X-Tenant-Id; JSON payload returned to client.

⚠️ Issue 1: Leak Risks

If an API key is leaked (e.g. committed to public GitHub), anyone possessing the key can execute authorized operations until the developer manually revokes it in the dashboard.

⏳ Issue 2: No Self-Contained Expiry

Unlike JWTs with standard exp timestamp claims, raw API keys are opaque strings without self-verifying expiration. Expiration and rotation schedules must be managed server-side.

💡 Crucial Architectural Distinction: API Keys vs. JWT

API Keys are opaque random identifiers requiring a server-side database/Redis lookup to identify the caller and verify permissions.
In contrast, JWTs are cryptographically signed payloads carrying serialized claims (user ID, expiration, roles) that any downstream service can verify statelessly without querying a central database.

6 Protocol Comparison: Basic vs. Digest vs. API Keys

Authentication Scheme	Credential Format	Replay Protection	State Management	Primary Modern Use Case
HTTP Basic	Base64 encoded `user:pass`	❌ None	Stateless header; browser stores credentials in memory	Internal developer proxies, legacy appliances
HTTP Digest	MD5 hash with server nonce	✅ Nonce-based	Server must maintain nonce state / timestamp	Legacy embedded devices (mostly deprecated)
API Keys	Opaque high-entropy secret (e.g. `sk_live_…`)	⚠️ Requires HTTPS + optional HMAC signature	Stateful (requires DB/Redis lookup for identity & scopes)	Machine-to-Machine APIs, SaaS billing, rate limiting