30-Second Glance
- TLS everywhere (1.3, terminate at edge, re-encrypt inside); OAuth2/OIDC for delegated auth, short-lived JWT access tokens + opaque rotating refresh tokens, enforcement at the gateway.
- Sessions vs JWT is state-vs-scale: server sessions revoke instantly but need shared state; JWTs are stateless but need short TTLs + revocation discipline.
- Encrypt in transit (TLS) and at rest (AES-256 via KMS envelope encryption) by default; name the key lifecycle, not just the cipher.
- DDoS/WAF/rate-limiting is layered (edge absorb → WAF rules → per-tenant throttling); secrets live in a manager with rotation, never env files or repos.
- Interview scope only: enough to place auth, encryption, and abuse controls on an HLD diagram — not a security textbook.
TLS: The Non-Negotiable Baseline
Every hop encrypted: client→edge, edge→service, service→service (mTLS in a service mesh like Istio/Linkerd, or at minimum TLS inside the VPC — "it's inside the VPC" is not a threat model). TLS 1.3 (1-RTT handshake, forward secrecy by default, ~1–2 ms added p99 with session resumption), certificates auto-rotated via ACM/Let's Encrypt, HSTS + redirect http→https at the edge. Terminate TLS at the load balancer/gateway for centralized cipher policy and WAF inspection, then re-encrypt to backends — termination without re-encryption leaves east-west traffic sniffable by any compromised host. In the interview: draw the padlock on every arrow crossing a trust boundary and say "TLS 1.3, terminate at gateway, re-encrypt to services, mTLS where the mesh gives it free."
AuthN/AuthZ: OAuth2, OIDC, JWT, Sessions
OAuth2 + OIDC (delegated auth)
OAuth2 is authorization delegation ("let app X act on my Google/GitHub data without my password") via flows: authorization-code + PKCE for web/mobile (the only browser-safe flow — never implicit), client-credentials for service-to-service. OIDC layers authentication on top (id_token JWT asserting who the user is). Concrete: "Login with Google" = OIDC code flow → gateway validates id_token, mints internal session/token. Service-to-service uses client-credentials or workload identity (SPIFFE/IRSA — cloud IAM roles for pods, no static secrets).
JWT access tokens vs server sessions
| Stateful session (opaque ID + store) | Stateless JWT | |
|---|---|---|
| Lookup | Redis/DB hit per request (~0.5–2 ms) | Verified locally via signature/JWKS (no I/O) |
| Revocation | Instant (delete row) | Hard — needs short TTL (5–15 min) + denylist or rotation |
| Size/scale | Tiny cookie; store must scale + replicate | Self-contained but ~1 KB per request header; key rotation via JWKS |
| Best for | Web apps needing instant logout/ban | API gateways, mobile, cross-service propagation |
The standard FAANG answer is the hybrid: short-lived JWT access token (5–15 min) + rotating opaque refresh token (stored server-side, reuse detection = theft signal). Gateway validates JWT (signature + expiry + audience/issuer), services trust gateway claims plus re-verify. Never put sensitive data in JWT payloads (they're signed, not encrypted), never accept alg: none, always check exp/aud/iss.
RBAC (and when it isn't enough)
Role-based access control: users → roles → permissions (admin, seller, buyer; service roles per endpoint scope like orders:read). Enforced at gateway (coarse: is this token allowed on this route?) and service (fine: does this seller own order 42?). Store the role graph in the user/auth service, cache decisions briefly, and propagate least-privilege scopes in tokens. Name the successors in one line: ABAC (attribute policies — "owner + business hours + region") and ReBAC (relationship graphs — "document shared with team") for Google-Drive-style problems; default to RBAC unless the prompt demands finer.
Encryption: At Rest, In Transit, and the Keys
- In transit: TLS 1.3 everywhere (above); plus signed URLs (S3/GCS, 5–60 min expiry) so private objects never proxy through your servers.
- At rest: AES-256 for DBs/disks/backups (RDS/EBS/S3-SSE — one checkbox, but say it), field-level encryption for PII/secrets columns (SSN, tokens) so a DB dump without the KMS key is useless, bcrypt/argon2id for passwords (never reversible encryption — salted slow hashes, cost factor tuned to ~200–500 ms).
- Envelope encryption + KMS: data key encrypts data, master key in KMS/HSM wraps data keys; services get decrypt rights via IAM, humans never see keys. Key rotation (annual + on incident) and per-tenant/per-service key scoping complete the answer. The interview line: "AES-256 at rest via KMS envelope encryption, TLS 1.3 in transit, argon2 for passwords — and rotation + least-privilege IAM on the keys, because key management is the actual system."
Abuse Control: DDoS, WAF, Rate Limiting
Layered, outside-in:
- Edge absorption: CloudFront/Cloudflare/Akamai + Shield-style L3/L4 protection absorb volumetric attacks (100s of Gbps–Tbps at major CDNs); DNS with anycast; static content cached so origin never sees the flood.
- WAF rules: AWS WAF / Cloudflare rulesets for OWASP Top-10 (SQLi, XSS, SSRF), bot management, geo/IP blocklists, and per-route stricter rules (login/checkout get CAPTCHA/bot-score gates).
- Rate limiting + throttling: per-IP, per-user, per-API-key token/leaky buckets at gateway (e.g. 100 rps per key, login 5 attempts/min/IP with exponential lockout); costly endpoints (search, report export) get tighter quotas and async-ification; say the backoff headers (
429+Retry-After). - Abuse economics: idempotency keys + CAPTCHA/bot scores on money paths, webhook signature verification (HMAC shared secret / public key), SSRF guards on any user-supplied URL fetch (allowlist + metadata-IP block
169.254.169.254), and upload discipline (size caps, type sniffing, AV scan, serve from separate cookie-less domain).
Size it: "login limited to 5/min/IP with account-level throttling, API keys at 100 rps with burst 200, checkout behind bot-score + idempotency keys" — concrete numbers beat "we rate limit."
Secrets and Hygiene
Secrets (DB passwords, API keys, signing keys) live in a secrets manager (AWS Secrets Manager / Vault / GCP Secret Manager) with encryption at rest, IAM-scoped access, automatic rotation (RDS rotation lambda, dual-password support), and injection at runtime — never in repos, images, env files, or logs (sanitize + PII redaction in the logging pipeline from Observability and Operations). Supporting hygiene in one breath: least-privilege IAM per service (no * policies), security groups/NACLS default-deny with explicit ingress, audit logs for authz decisions and key usage (append-only, separate account), dependency scanning + base-image patching cadence, and PII minimization/retention policy (can't leak what you don't store; GDPR delete path designed, not bolted on).
Trade-offs
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| mTLS everywhere (mesh) | Mutual auth + encryption free per hop | Mesh ops complexity, cert-rotation machinery | ≥10 services or regulated data |
| Edge-TLS + plaintext inside VPC | Simple, fast | Lateral sniffing after any host compromise | Prototypes only — name to reject |
| Stateless JWT only | No session store, easy scale | Revocation pain, token theft window | Short-lived internal propagation behind gateway validation |
| Server sessions only | Instant revocation, tiny cookies | Shared store becomes hot path + failover state | Web apps where instant logout/ban is required |
| JWT (5–15 min) + rotating refresh | Stateless hot path, revocable sessions, theft detection | Two-token machinery | Default for user auth — say this |
| Permissive internal network | Easy debugging | Breach anywhere = breach everywhere | Never — default-deny + explicit ingress |
| Aggressive rate limits | Cheap DDoS/abuse shield | False positives on legit bursts (NAT, launches) | Tiered: strict on auth/money, generous on reads, 429+Retry-After |
Interview One-Liners
- Q: Where do you enforce auth in microservices? A: Gateway validates tokens and enforces coarse scopes; each service re-checks fine-grained ownership — never trust client claims past the edge.
- Q: Sessions or JWT? A: Hybrid — 5–15 min JWT for the stateless hot path plus rotating opaque refresh tokens server-side, giving fast verification with revocable sessions and reuse-detected theft.
- Q: How do services authenticate to each other? A: mTLS via the mesh or OAuth2 client-credentials / workload identity (IAM roles for pods) — no static shared secrets baked into configs.
- Q: How is data protected at rest and in transit? A: TLS 1.3 everywhere with re-encryption past the edge; AES-256 at rest under KMS envelope encryption with rotation; argon2 for passwords, field-level encryption for PII columns.
- Q: Design login against brute force and credential stuffing. A: 5 attempts/min/IP with lockout, bot-score/CAPTCHA gate, argon2 hashes, breached-password screening, and anomaly alerts on the auth-failure metrics.
- Q: How do you survive a DDoS on checkout? A: CDN edge absorption, WAF bot rules, per-key rate limits with 429+Retry-After, static caching so origin only sees dynamic checkouts, and idempotency keys making retries safe.
- Q: Where do secrets live? A: Secrets manager with IAM-scoped runtime injection and auto-rotation — nothing in repos, images, env files, or logs.
Related
- Microservices Patterns — gateway as the auth enforcement point
- Observability and Operations — audit logs, auth-failure SLIs, PII redaction
- Messaging and Event Queues — signed webhooks, idempotency keys on money paths
- CAP, PACELC and Consistency Models — why session stores and revocation lists favor CP placement