Courses › System Design › Core Concepts

Authentication & Authorization

Sessions vs JWTs, OAuth and OIDC, API keys, RBAC/ABAC/ReBAC and where to enforce checks.

Authentication (authn) answers "who are you?" Authorization (authz) answers "what are you allowed to do?" Interviewers rarely want a full security design, but nearly every API needs both, and a crisp sentence about how requests are authenticated and permissions are checked closes an obvious gap. Some questions — post privacy, Google Drive-style sharing, multi-tenant SaaS — are mostly about authorization.

Authenticating users

Sessions

  • After login, the server creates a session record (in Redis or a database) and sends the client an opaque session ID in an HttpOnly, Secure, SameSite cookie.
  • Each request looks up the session. Revocation is instant — delete the record.
  • Costs one lookup per request; fine for most web apps.

Tokens (JWT)

  • The server issues a signed token containing claims (sub: user_42, roles, exp). Any service can verify the signature with a public key — no lookup needed.
  • Downside: a token stays valid until it expires, so revocation is hard. Use short-lived access tokens (5–15 minutes) plus a longer-lived refresh token that is stored server-side and can be revoked.
  • Keep tokens small and never put secrets in them — a JWT is signed, not encrypted.

OAuth 2.0 and OpenID Connect

  • OAuth 2.0 lets a user grant an app limited access to their data on another service without sharing their password ("Allow this app to read your calendar"). The app receives an access token with specific scopes.
  • OpenID Connect (OIDC) builds login on top of OAuth ("Sign in with Google"), adding an ID token that identifies the user.
  • Use the authorization code flow with PKCE for web and mobile apps.

Other credentials

  • API keys — simple per-client secrets for server-to-server or developer APIs. Store only a hash, support rotation, and scope them.
  • mTLS — services authenticate each other with certificates, often handled automatically by a service mesh (Envoy).
  • Passwords — hash with a slow algorithm (bcrypt, scrypt, Argon2), rate-limit login attempts, and support MFA.

Authorization models

Google Zanzibar is the reference design for ReBAC at scale: permissions are stored as relation tuples (doc:42#viewer@group:eng#member) and checked by a dedicated, heavily cached authorization service. Open-source equivalents include SpiceDB and OpenFGA.

Where to enforce it

[Client] -> [API Gateway: authenticate token, rate limit] -> [Service: authorize action on resource] -> (Database)
  • Authenticate at the edge — the API gateway validates the session or token and passes a verified user identity to services.
  • Authorize in the service that owns the resource, because only it knows who owns what. Check every request — never rely on IDs being unguessable.
  • Enforce tenant isolation in every query (WHERE tenant_id = ?), ideally automatically through a data-access layer or row-level security.

[!WARNING] Broken object-level authorization The most common API vulnerability is GET /documents/123 returning document 123 to anyone who's logged in. Always check that the caller may access *that specific* object.

[!INTERVIEW] Shared documents "Users sign in through OIDC; the gateway validates a 10-minute JWT and forwards the user ID. Sharing is relationship-based — owner, editor, viewer, inherited through folders — stored as tuples in a Zanzibar-style permission service. The document service calls it on every read and write, with results cached for a few seconds and invalidated when sharing changes."