Security Basics | System Design Interview Handbook

🪪

Authentication

who are you — sessions vs JWTs

Authentication proves identity. After login, the server issues something the client presents on later requests, and the two dominant approaches differ in where the state lives.

  SESSION + COOKIE                       JWT (JSON Web Token)
  server stores session, sends an ID     server signs a token holding the claims
     client ─cookie(id)─▶ server            client ─token─▶ server
     server looks up id in session store    server verifies the SIGNATURE, no lookup
     ▶ state on the SERVER                   ▶ state in the TOKEN (stateless)
     ▶ revoke = delete the session (easy)    ▶ revoke = hard (valid till it expires)

	Sessions	JWT
State	Server-side store	In the token, stateless
Scaling	Needs a shared session store	Any server verifies alone
Revocation	Easy — delete the session	Hard — valid until expiry
Best for	Classic web apps	APIs, microservices, mobile

💡

The JWT revocation problem is the tell. Because a signed token is valid until it expires, you can't instantly revoke it — so keep access tokens short-lived (minutes) and pair them with a longer-lived refresh token you can revoke at the store. OAuth2 / OIDC is the standard for delegated authorization — "sign in with Google" hands you a token without the app ever seeing the password.

🚦

Authorization

what are you allowed to do

Authentication is who you are; authorization is what you're allowed to do. Different problems, often conflated. A valid login (authN) doesn't mean you can delete another user's data (authZ). RBAC — role-based access control — is the default model: assign users roles, grant permissions to roles, check the role on each action.

ℹ️

Enforce at two levels. The gateway does coarse checks — is this token valid, does this role reach this service at all — cheaply at the edge. The service does fine-grained checks it alone can make: does this user own this specific record. The gateway can't know the second; never rely on it for object-level authorization (Discovery).

🔐

Encryption

in transit, at rest, and hashing

Two states to protect, plus one thing that isn't encryption at all.

In transit TLS everywhere

TLS on every connection, including service-to-service. In a zero-trust design, internal calls use mTLS — both sides present certificates, so services mutually authenticate and the internal network isn't assumed safe (TLS).

At rest disk and field

Disk and database encryption protect data if the storage is stolen. For the truly sensitive — SSNs, card numbers — add field-level encryption so a single leaked field is useless without the key.

⚠️

Hashing is not encryption. Encryption is reversible with a key; hashing is one-way. Passwords must be hashed, never encrypted — with a slow, salted algorithm like bcrypt or argon2 that resists brute force. If your system can decrypt a stored password back to plaintext, that's the bug. You verify a login by hashing the input and comparing, never by decrypting.

🗝

Secrets Management

keys, tokens, and where they don't go

API keys, database passwords, and signing keys are secrets, and they do not belong in code or committed env files — one leaked repo and they're public forever. Store them in a dedicated secret store — Vault, or a cloud KMS — that services fetch from at runtime with tight access control, and rotate them periodically so a leaked secret has a short useful life.

⚠️

A hardcoded secret is a breach waiting to happen — it lives in git history even after you delete it, and anyone with repo access has it. "Secrets in a vault, rotated, never in code" is a one-line answer that signals you've operated real systems, not just built them.

🧱

The Perimeter

defense in depth

No single control is enough — you layer them so one failure doesn't mean a breach. That's defense in depth.

Control	Guards against
Rate limiting	Abuse, credential stuffing, scraping (Scaling)
Input validation at the edge	Injection, malformed payloads — reject early
Least privilege between services	A compromised service can't reach everything
Defense in depth	One bypassed layer isn't game over

ℹ️

Least privilege is the principle underneath most of this: every service, token, and key gets the minimum access it needs and nothing more. When a component is inevitably compromised, least privilege bounds the blast radius to what that one thing could touch (Resilience).

📋

Quick Reference

sessions vs JWT, and the lines to say

	Sessions	JWT
State	Server-side	In the token
Revocation	Easy (delete session)	Hard (short expiry + refresh)
Scaling	Shared session store	Stateless verify
Fits	Web apps	APIs, mobile, microservices

Security lines to say during a design
TLS everywhere, mTLS between services in zero-trust
Passwords hashed with bcrypt/argon2, never encrypted
AuthZ at the gateway (coarse) and service (fine-grained)
Secrets in a vault, rotated, never in code
Rate limiting + input validation at the edge; least privilege throughout

ℹ️

The one-liners to keep ready. AuthN is who you are, authZ is what you can do — enforce authZ coarse at the gateway and fine at the service. Sessions store state server-side and revoke easily; JWTs are stateless but hard to revoke, so keep them short with refresh tokens. TLS everywhere, hash passwords with bcrypt/argon2, keep secrets in a vault, and layer controls for defense in depth.