Episode 9 — System Design / 9.10 — Advanced Distributed Systems
9.10.e — Authentication and Authorization
Introduction
Authentication (AuthN) and authorization (AuthZ) are the gatekeepers of every system. They determine who you are and what you can do. In system design interviews, security is a cross-cutting concern you should mention for any system handling user data, payments, or sensitive operations.
1. Authentication vs Authorization
+------------------------------------------------------------------------+
| |
| AUTHENTICATION (AuthN) AUTHORIZATION (AuthZ) |
| "WHO are you?" "WHAT can you do?" |
| |
| +------------------+ +------------------+ |
| | Username/Password| | Role: admin | |
| | Fingerprint | | Permission: | |
| | OAuth token | --------> | read: yes | |
| | API key | identity | write: yes | |
| | Certificate | verified | delete: no | |
| +------------------+ +------------------+ |
| |
| Happens FIRST Happens SECOND |
| "Prove your identity" "Check your permissions" |
| |
| Failure: 401 Unauthorized Failure: 403 Forbidden |
+------------------------------------------------------------------------+
| Authentication | Authorization | |
|---|---|---|
| Question | Who are you? | What can you access? |
| Mechanism | Credentials, tokens, certificates | Roles, permissions, policies |
| HTTP status on failure | 401 Unauthorized | 403 Forbidden |
| Example | Login with email + password | Admin can delete, viewer can only read |
| Changes when | User changes password | User's role changes |
2. Session-Based vs Token-Based Authentication
Session-Based
Client Server
| |
|--- POST /login (creds) ------>|
| |--- Create session in DB/Redis
| | session_id = "abc123"
|<-- Set-Cookie: sid=abc123 ----|
| |
|--- GET /api/data |
| Cookie: sid=abc123 ------->|
| |--- Lookup session in store
| | Found: user_id=42
|<-- 200 OK (data) ------------|
| |
|--- POST /logout ------------->|
| |--- Delete session from store
|<-- Clear cookie --------------|
Token-Based (JWT)
Client Server
| |
|--- POST /login (creds) ------>|
| |--- Verify credentials
| |--- Create JWT (signed)
|<-- { token: "eyJhbG..." } ----|
| |
|--- GET /api/data |
| Authorization: Bearer |
| eyJhbG... ----------------->|
| |--- Verify JWT signature
| | (NO database lookup needed)
| | Decode: { user_id: 42, role: "admin" }
|<-- 200 OK (data) ------------|
Comparison
| Aspect | Session-Based | Token-Based (JWT) |
|---|---|---|
| State | Stateful (server stores sessions) | Stateless (token is self-contained) |
| Storage | Server-side (Redis/DB) | Client-side (localStorage, cookie) |
| Scalability | Harder (shared session store needed) | Easier (any server can verify) |
| Revocation | Easy (delete session from store) | Hard (token valid until expiry) |
| Cross-domain | Difficult (cookies are domain-scoped) | Easy (token sent in header) |
| Mobile-friendly | Less (cookies awkward on mobile) | More (token in header is universal) |
| Use case | Traditional web apps | SPAs, mobile apps, microservices |
3. JWT (JSON Web Token) Deep Dive
Structure
+------------------------------------------------------------------------+
| JWT STRUCTURE |
| |
| eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Mn0.SflKxwRJSMeKKF2QT4fwp |
| |_______HEADER_______|.|______PAYLOAD______|.|_____SIGNATURE_____| |
| |
| HEADER (Base64): PAYLOAD (Base64): SIGNATURE: |
| { { HMAC-SHA256( |
| "alg": "HS256", "user_id": 42, base64(header) + |
| "typ": "JWT" "role": "admin", "." + |
| } "exp": 1720000000, base64(payload), |
| "iat": 1719996400 secret_key |
| } ) |
+------------------------------------------------------------------------+
Common JWT Claims
| Claim | Name | Purpose |
|---|---|---|
iss | Issuer | Who created the token |
sub | Subject | Who the token is about (user ID) |
aud | Audience | Who the token is intended for |
exp | Expiration | When the token expires (Unix timestamp) |
iat | Issued At | When the token was created |
jti | JWT ID | Unique ID for the token (for revocation) |
JWT Refresh Token Pattern
Client Auth Server API Server
| | |
|-- Login (creds) -------------->| |
|<- Access Token (15 min) -------| |
| + Refresh Token (7 days) | |
| | |
|-- API call + Access Token -----|--------------------------->|
|<- 200 OK -------------------- | ----------------------------|
| | |
| ... 15 minutes later ... | |
| | |
|-- API call + Access Token -----|--------------------------->|
|<- 401 Token Expired ---------- | ----------------------------|
| | |
|-- Refresh Token -------------->| |
|<- New Access Token (15 min) ---| |
| | |
|-- API call + New Access Token -|--------------------------->|
|<- 200 OK ----------------------|----------------------------|
Why two tokens?
- Access token: short-lived (15 min), used for every request, not easily revocable
- Refresh token: long-lived (7 days), stored securely, used only to get new access tokens, revocable (stored in DB)
4. OAuth 2.0
OAuth 2.0 is a framework for delegated authorization -- allowing third-party apps to access user data without sharing credentials.
Authorization Code Flow (Most Common)
User Client App Auth Server Resource Server
| | | |
|-- Click | | |
| "Login | | |
| with | | |
| Google" ->| | |
| |-- Redirect to -->| |
| | /authorize | |
| | ?client_id=X | |
| | &redirect_uri | |
| | &scope=email | |
| | &state=random | |
| | | |
|<------------|-- Google login --| |
|-- Enter credentials --------->| |
| | |
|<-- Redirect to redirect_uri --| |
| ?code=AUTH_CODE | |
| &state=random | |
| | | |
| |-- POST /token -->| |
| | code=AUTH_CODE | |
| | client_secret | |
| |<- Access Token --| |
| | + Refresh Tkn | |
| | | |
| |-- GET /userinfo -|----------------->|
| | Bearer token | |
| |<- User data -----|-------------------|
|<- Logged in -| | |
OAuth 2.0 Grant Types
| Grant Type | Use Case | Security Level |
|---|---|---|
| Authorization Code | Server-side web apps | Highest (code exchange is server-to-server) |
| Authorization Code + PKCE | SPAs, mobile apps | High (prevents code interception) |
| Client Credentials | Service-to-service (no user) | High (server-side only) |
| Device Code | Smart TVs, IoT (no browser) | Moderate |
5. Single Sign-On (SSO)
+------------------------------------------------------------------------+
| SSO FLOW (SAML / OIDC) |
| |
| User visits App A User visits App B |
| | | |
| v v |
| "Not logged in" "Not logged in" |
| | | |
| v v |
| Redirect to IdP Redirect to IdP |
| (Identity Provider) (same IdP) |
| | | |
| v v |
| +----+---------------------------+----+ |
| | IDENTITY PROVIDER (IdP) | |
| | (Okta, Auth0, Google, Azure AD) | |
| | | |
| | First visit: Show login form | |
| | Subsequent: Already authenticated, | |
| | issue token immediately | |
| +----+---------------------------+----+ |
| | | |
| v v |
| Token for App A Token for App B |
| (User logged in) (User logged in, no re-login!) |
+------------------------------------------------------------------------+
SSO protocols:
- SAML 2.0: XML-based, enterprise-focused, older but widely deployed
- OpenID Connect (OIDC): Built on OAuth 2.0, JSON/JWT-based, modern, simpler
6. RBAC vs ABAC
RBAC (Role-Based Access Control)
+------------------+ +-----------------+ +------------------+
| USERS | | ROLES | | PERMISSIONS |
+------------------+ +-----------------+ +------------------+
| Alice |---->| admin |---->| read: * |
| Bob |---->| editor |---->| write: articles |
| Charlie |---->| viewer |---->| read: articles |
+------------------+ +-----------------+ +------------------+
Check: Does Bob's role (editor) have permission to write articles? YES
ABAC (Attribute-Based Access Control)
+------------------------------------------------------------------+
| POLICY: Allow IF |
| user.department == "engineering" |
| AND resource.classification != "top-secret" |
| AND time.current_hour BETWEEN 9 AND 18 |
| AND user.location == resource.region |
+------------------------------------------------------------------+
Check: Is Bob (dept: engineering) accessing non-secret doc
at 2pm from US region? --> Evaluate all attributes --> YES
Comparison
| Aspect | RBAC | ABAC |
|---|---|---|
| Model | User -> Role -> Permission | Policy rules on attributes |
| Granularity | Coarse (role-level) | Fine (attribute-level) |
| Complexity | Simple to implement | Complex to manage |
| Flexibility | Limited (add new role for new need) | Very flexible (new policy = new rule) |
| Performance | Fast (role lookup) | Slower (policy evaluation) |
| Best for | Most applications, clear role hierarchies | Healthcare, finance, government (complex rules) |
| Examples | GitHub (owner, maintainer, member) | AWS IAM policies, hospital records access |
7. API Keys
+------------------------------------------------------------------------+
| API KEY USAGE |
| |
| Client: |
| GET /api/weather?city=London |
| X-API-Key: sk_live_abc123def456 |
| |
| Server: |
| 1. Extract API key from header |
| 2. Look up key in database: |
| - Which app/user owns this key? |
| - Is the key active? |
| - What tier/quota does it have? |
| 3. Apply rate limits for that tier |
| 4. Process request |
| |
| API Key vs Token: |
| +------------------+------------------------------------------+ |
| | API Key | Identifies the APPLICATION | |
| | | Long-lived, used for server-to-server | |
| +------------------+------------------------------------------+ |
| | Access Token | Identifies the USER + permissions | |
| | | Short-lived, used for user-facing flows | |
| +------------------+------------------------------------------+ |
+------------------------------------------------------------------------+
8. Auth in Microservices (Gateway-Level Auth)
+------------------------------------------------------------------------+
| GATEWAY-LEVEL AUTH PATTERN |
| |
| Client |
| | |
| | Authorization: Bearer eyJhbG... |
| v |
| +------------------+ |
| | API GATEWAY | 1. Validate JWT signature |
| | (Kong / Envoy | 2. Check expiry |
| | / AWS API GW) | 3. Extract user_id, roles |
| +--------+---------+ 4. Attach user context to internal request |
| | |
| X-User-Id: 42 |
| X-User-Role: admin |
| | |
| +------+------+------+ |
| | | | | |
| v v v v |
| [Order] [Pay] [Inv] [User] <-- Internal services trust |
| the gateway headers |
| (no re-validation) |
+------------------------------------------------------------------------+
Alternative: Service Mesh Auth (mTLS)
+----------+ mTLS +----------+ mTLS +----------+
| Service A| <----> | Service B| <----> | Service C|
+----------+ +----------+ +----------+
| | |
[Sidecar Proxy] [Sidecar Proxy] [Sidecar Proxy]
(Istio / Envoy) (Istio / Envoy) (Istio / Envoy)
- Each service has a certificate (identity)
- mTLS encrypts all inter-service communication
- The mesh enforces authorization policies
9. Security Best Practices
| Practice | Details |
|---|---|
| Hash passwords | bcrypt / scrypt / Argon2 (never MD5/SHA1) |
| Use HTTPS everywhere | TLS 1.3, HSTS headers |
| Store secrets securely | Vault, AWS Secrets Manager (never in code/env vars) |
| Short-lived tokens | Access tokens: 15 min. Refresh tokens: 7 days. |
| Rotate secrets regularly | API keys, certificates, signing keys |
| Principle of least privilege | Grant minimum permissions needed |
| Rate limit auth endpoints | Prevent brute-force attacks |
| Validate input always | SQL injection, XSS, CSRF prevention |
| Log auth events | Failed logins, privilege escalations, token refreshes |
| Implement MFA | TOTP, WebAuthn, SMS (as last resort) |
10. Auth in System Design Interviews
+-----------------------------------------------------------------------+
| AUTH TALKING POINTS FOR INTERVIEWS |
| |
| 1. "Authentication at the API gateway -- JWT validation |
| before requests reach internal services" |
| |
| 2. "OAuth 2.0 for third-party integrations, |
| JWT for internal user sessions" |
| |
| 3. "RBAC for permission management |
| (admin, editor, viewer roles)" |
| |
| 4. "Short-lived access tokens (15 min) + |
| refresh tokens (7 days) for security" |
| |
| 5. "mTLS between microservices via service mesh |
| for zero-trust internal communication" |
| |
| Keep it brief unless the interviewer digs deeper. |
+-----------------------------------------------------------------------+
Key Takeaways
- AuthN is "who are you?" AuthZ is "what can you do?" Always handle authentication first, then authorization.
- JWT is the standard for modern systems. Stateless, scalable, cross-domain friendly.
- Use the refresh token pattern. Short-lived access token + long-lived refresh token balances security and UX.
- OAuth 2.0 Authorization Code + PKCE is the recommended flow for both server-side and client-side apps.
- RBAC is sufficient for most systems. ABAC adds flexibility at the cost of complexity.
- Auth at the gateway is the microservices pattern. Validate once at the edge, pass trusted context internally.
- mTLS via service mesh secures inter-service communication in zero-trust architectures.
- Never store plaintext passwords. Use bcrypt/Argon2. Never roll your own crypto.
Explain-It Challenge
Design question: You are designing the auth system for a multi-tenant SaaS platform where:
- Users belong to organizations
- Each organization has admins, editors, and viewers
- Organizations can invite external collaborators with limited access
- Third-party apps can access the API via OAuth
Sketch the auth architecture: What tokens do you use? Where is auth validated? How do you handle cross-org permissions?
Next -> 9.10.f — Search Systems