Authentication and Authorization Questions

Cover core concepts and implementation trade offs for securing backend services. Candidates should demonstrate understanding of token based authentication and server side session strategies, how to securely issue and rotate credentials, techniques for revocation and refresh, secure storage of secrets, use of third party identity providers, common threat mitigations such as cross site request forgery protection and secure transmission practices, and design patterns for role based and attribute based access control. Interviewers will evaluate the candidate ability to reason about scalability and revocation trade offs and to design secure application programming interface permission checks.

EasyTechnical

63 practiced

Describe the differences between access tokens and refresh tokens: intended lifetimes, storage recommendations, attack surface, and typical use patterns in web and mobile clients. Explain why refresh tokens generally require stronger protections and how rotation reduces risk.

Sample Answer

**Clear definitions**- Access token: short-lived credential (minutes → hours) used to call APIs. Bearer semantics: possession = access.- Refresh token: long-lived credential (hours → months) used to obtain new access tokens without re-authentication.

**Intended lifetimes**- Access: short to limit window of misuse.- Refresh: longer to improve UX (silent renew), but should be constrained by scopes, device, and policy.

**Storage recommendations**- Web (browser): - Access: in-memory or short-lived httpOnly Secure SameSite cookie to reduce XSS exposure. - Refresh: httpOnly Secure SameSite cookie (server-set) or avoid exposing in JS.- Mobile: - Use platform secure storage (iOS Keychain, Android Keystore/EncryptedSharedPreferences) for both tokens; prefer refresh in secure enclave/keystore.- Never store tokens in localStorage or unencrypted files.

**Attack surface**- Access token: exposed to XSS, network interception if TLS fails, longer-lived if misconfigured.- Refresh token: higher-value target — if stolen it grants new access tokens over a long window and enables account takeover.

**Typical use patterns**- Web SPA: store access in memory; refresh via rotation endpoint using httpOnly cookie or silent iframe.- Server-side web apps: store tokens server-side; use session cookie; server performs token exchange.- Mobile apps: silent refresh with refresh token from secure storage.

**Why refresh tokens need stronger protections**- They mint access tokens; compromise yields persistent access and replay across devices. They must be minimized in exposure, scoped, and revocable.

**How rotation reduces risk**- Rotation issues a new refresh token on each use and invalidates the previous one (one-time use). If an attacker replays an old refresh token, detection triggers immediate revocation and session termination, limiting abuse window and enabling detection of token theft. Combine rotation with binding (sender-constrained tokens) and monitoring for anomalous use for stronger protection.

HardSystem Design

70 practiced

Design a token revocation system that supports immediate global revocation for compromised access and refresh tokens in a geo-distributed environment serving millions of tokens. Describe your choices for data stores, invalidation propagation (pub/sub, edge caches, bloom filters), trade-offs between immediacy and scalability, and how to handle partitions and operational complexity.

Sample Answer

**High-level approach**I’d design a hybrid, multi-layer revocation system: authoritative revocation store for correctness + low-latency edge invalidation for immediate enforcement. Tokens carry a version/ID and issuance timestamp to enable fast checks without full DB hits.

**Data stores**- Authoritative store: strongly consistent, geo-replicated KV (e.g., DynamoDB Global Tables or CockroachDB) holding revoked token IDs, user revocation counters, and compromised key metadata.- Fast cache: distributed in-memory cache at each region (Redis cluster with persistence) for hot revocations and counter lookups.- Durable audit/log: append-only store in S3 or Kafka for forensic and replay.

**Invalidation propagation**- Immediate: publish revocation events to global pub/sub (Kafka or managed pubsub) with partitioning by account; regional gateways subscribe and populate local Redis caches.- Edge caches: each edge (API gateway / auth proxy) checks local Redis first; if miss, consult Bloom filter (local, compact) to avoid unnecessary DB hits; on Bloom-hit perform synchronous introspection to authoritative store.- Bloom filters: per-region, periodically rebuilt from authoritative store to give cheap probable-negative checks; accept false positives (extra DB check) but no false negatives.- Token versioning: increment user revocation counter on mass-compromise; tokens include counter so any token with stale counter rejected without consulting DB.

**Immediacy vs scalability trade-offs**- Immediate global revocation requires synchronous propagation — expensive at scale. Trade: - Strong immediacy: push to all regions synchronously (higher latency and ops cost). - Practical approach: prioritize push for high-risk tokens (admin, long-lived refresh tokens) and use short TTLs + Bloom filters + fallback introspection for low-risk tokens.- Use leaky-bucket rate limits for revocation storms; enforce per-account throttling.

**Partitioning and failure modes**- Network partitions: authoritative store uses quorum writes; if region isolated, fall back to local enforcement using last-known revocation set + token TTLs. For critical revocations, mark account as "frozen" and force re-auth on next request.- Eventual-consistency window: minimize by fast pub/sub and acked writes; detect missed subscribers via consumer offsets and repair via replay from durable log.- Conflict resolution: revocation is monotonic (only add), so conflicts are simple — use vector timestamps or sequence numbers to apply in order.

**Operational complexity & mitigations**- Observability: track propagation lag, cache hit/miss, bloom false-positive rates, and revocation queue length.- Automation: scripts to rebuild Bloom filters, replay missed events, and rotate keys.- Testing & playbooks: chaos testing for partitions, revoke drills, incident runbooks to freeze accounts and escalate.- Security controls: protect pub/sub and caches (mTLS, ACLs), encrypt data at rest, and limit access to revocation APIs.- Cost controls: tier revocation handling (immediate for critical), TTLs for short-lived tokens, and sampling of non-critical revocations.

This design balances immediate security needs for compromised tokens with global scale and operational practicality through layered checks (edge cache → Bloom → introspection), monotonic revocation semantics, prioritized propagation, and robust failover behavior.

EasyTechnical

84 practiced

Explain the structure of a JSON Web Token (JWT): header, payload, signature. Describe common claims (iss, sub, aud, exp, iat, nbf, jti, scope) and what each should be used for. Discuss how to design claims to avoid over-privileging and to minimize token size for mobile and network-sensitive environments.

Sample Answer

**Structure of a JWT**- **Header**: metadata — typ (JWT), alg (e.g., RS256). Used by receivers to choose verification method.- **Payload (claims)**: statements about subject and context. Not encrypted by default — treat as public.- **Signature**: sign( base64url(header) + "." + base64url(payload) ) — ensures integrity and authenticity.

**Common claims & recommended uses**- iss (issuer): identifier of token issuer (use URL or service ID). Validate strictly.- sub (subject): unique principal identifier (user id). Use stable, non-guessable IDs.- aud (audience): intended recipient(s) (service IDs). Reject if mismatch.- exp (expiration): epoch time token becomes invalid. Keep short for access tokens.- iat (issued at): issuance time — detect clock skew and replay windows.- nbf (not before): token not valid before this time — useful for future-dated tokens.- jti (JWT ID): unique token id — enable revocation/blacklisting for long-lived tokens.- scope: scoped permissions (space/comma separated) — prefer minimal, coarse-grained scopes.

**Design to avoid over-privileging**- Follow least privilege: issue tokens with minimal scope and short exp.- Prefer reference tokens (opaque IDs) for high privilege operations so server-side checks can change permissions.- Use audience and scope separation per service; avoid embedding roles/permissions broadly.- Constrain claims to machine-friendly keys; avoid granting admin-level flags unless necessary.

**Minimize token size for mobile/network**- Use short claim keys (e.g., "scp" instead of "scope") when safe and documented.- Avoid embedding full user profiles; include only identifiers and fetch details server-side.- Use compact signing (RS vs ES chosen for size) and avoid nested JWTs.- Consider token compression or using opaque tokens with small JWT-like IDs for constrained links.

As a Security Architect, codify these rules into token standards, issuance policies, and audit controls to ensure tokens remain small, least-privileged, and revocable.

MediumSystem Design

84 practiced

You must choose between an OAuth2 token introspection endpoint (centralized validation) and self-contained short-lived tokens validated locally by microservices for a system processing 10k requests/sec. Discuss performance, key rotation lifecycle, revocation timeliness, caching strategies, and propose a hybrid setup that balances scalability and security.

Sample Answer

**Clarify trade-offs (short summary)** Centralized introspection gives immediate revocation decisions and minimal local crypto but is a scalability/network bottleneck. Self-contained short-lived tokens (JWTs) enable local, high-throughput validation but make fast revocation and key rotation more complex.

**Performance at 10k RPS** - Self-contained: local cryptographic verify (RSA/ECDSA) — ~1–3ms/verify with optimized libs and JIT; scales horizontally without network calls. Good cache hit amplification reduces CPU. - Introspection: each request causes network hop; at 10k RPS requires a highly available, horizontally scaled introspection service (load balancers, autoscale, connection pooling) and adds latency (~5–20ms plus queuing).

**Key rotation lifecycle** - Use short-lived signing keys + key IDs (kid). Publish JWKS endpoint; retain old keys for max(token TTL)+safety window. Rotate keys with automated rollout, monitor usage, and retire after TTL window. Use asymmetric keys to avoid symmetric secret distribution.

**Revocation timeliness** - Introspection: immediate — single source of truth. - Self-contained: constrained by token TTL. Mitigate with short TTLs (e.g., 1–5 minutes) and active revocation caches (see below).

**Caching strategies** - For introspection: API gateway caches introspection responses per token for a short TTL (e.g., 30s) and use stale-while-revalidate to avoid thundering herd. - For self-contained: cache public JWKS and validation results (token id -> allow) in a distributed cache (Redis with EVICTION and short TTL). Use Bloom filters or revocation sets to cheaply reject revoked tokens.

**Recommended hybrid design** - Issue short-lived self-contained tokens (1–5m) signed with rotating keys. - Enforce local validation in microservices using JWKS cached locally. - Maintain a centralized introspection/revocation service: gateways and services consult it on first-seen tokens, on suspected compromise, or for long-lived refresh tokens. - Use a distributed revocation cache (Redis or CDN) populated by the introspection service; microservices check cache fast (in-memory + local LRU) before full crypto verify skip. - Instrument metrics/alerts for failed validations and rotate keys via CI/CD.

This balances high throughput and low latency with near-real-time revocation and manageable key lifecycle.

EasyBehavioral

127 practiced

Explain the principle of least privilege and provide a concrete example applying it to API permission design for an enterprise application. Identify entities involved, the minimal permissions you would grant, how you would enforce validation, and how you'd monitor and detect over-provisioned permissions.

Unlock Full Question Bank

Get access to hundreds of Authentication and Authorization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.