Authorization and Identity Systems Questions

Design, implementation, and operation of identity and authorization systems that control who can access which resources and actions across products and services. Areas include customer identity management and identity lifecycle, authentication and token management using JSON Web Tokens and OAuth flows, session and token refresh and revocation strategies, API key lifecycle and rotation, role based access control and attribute based access control models, policy evaluation engines and permissions data modeling, placement of enforcement points across gateway, service, and data layers, caching of authorization decisions and cache invalidation strategies, preventing privilege escalation and secure default permissions, threat modeling and secure storage of secrets, logging and auditing for compliance, rate limiting tied to identity, testing strategies for authorization, and operational practices such as monitoring, alerting, capacity planning, graceful degradation, incident response, and recovery for authorization services. Candidates without direct IAM experience should explain how core backend system skills translate to this domain.

MediumSystem Design

67 practiced

Design an audit logging pipeline for authentication and authorization events: define a structured log format, secure transport from apps to collectors, storage/indexing strategy for fast queries, tamper-evidence or immutability considerations, alerting, and cost-effective retention that meets compliance and forensic needs.

Sample Answer

**Clarify requirements & constraints**- Capture authN/authZ events across web, API, and services; support fast forensic queries (minutes), regulatory retention (e.g., 1–7 years), low cost, tamper-evidence, realtime alerting.

**Structured log format**- JSON schema (compact, typed) with required fields and schema version.

json

{
  "ts":"2026-03-02T12:34:56Z",
  "event_type":"auth.login",
  "service":"api-gateway",
  "user_id":"u-1234",
  "principal_type":"user|service|key",
  "outcome":"success|failure",
  "ip":"1.2.3.4",
  "client":"web:1.2.3",
  "reason":"invalid_password",
  "request_id":"r-uuid",
  "trace_id":"t-uuid",
  "raw_request":{ /* optional redacted */ }
}

- Validate at source (schema registry/JSON Schema), redact PII before transmission.

**Secure transport**- Use TLS 1.3 + mTLS from services to collectors (Fluentd/Vector) over private VPC endpoints.- Backpressure + local buffering (disk) for outages; sign payloads with service key to detect spoofing.

**Collectors & ingestion**- Edge collectors (Kubernetes DaemonSet or sidecars) aggregate, validate, add metadata, compute per-batch SHA256 and optional signature, forward to central pipeline (Kafka or managed Kinesis).

**Storage & indexing**- Hot index: Elasticsearch/OpenSearch or ClickHouse for 90 days for fast queries, with time-based indices and mappings on event_type, user_id, ip, outcome.- Cold archive: Compressed Parquet/JSONL to S3 with lifecycle (hot -> infrequent -> Glacier) for long-term retention and compliance.- Use partitioning by date + hashed service to accelerate scans; maintain inverted indices for common forensic fields.

**Tamper-evidence / immutability**- Write-once S3 with Object Lock in Governance/Compliance mode for retention windows.- Maintain an append-only ledger: store per-batch Merkle root in immutable store (e.g., blockchain anchor or signed daily checkpoint in KMS-backed DB). Validate hashes during audits.- Sign and timestamp batches with HSM/KMS keys.

**Alerting & detection**- Stream to SIEM (Splunk/Elastic SIEM/Chronicle) for realtime rules: multiple failed logins, impossible travel, privilege escalations.- Use threshold and anomaly detection (rate, geo, device fingerprint). Integrate with PagerDuty/Slack and include runbook links.

**Cost-effective retention**- Hot for 30–90 days (fast search); warm for 90–365 (less replicas); archive beyond to S3 Glacier. Keep indexed metadata (small footprint) for longer if needed.- Retention policy tied to compliance with automated lifecycle and audit logs of retention changes.

**Operational notes**- Monitor ingestion lag, schema drift, and data volume. Automate schema migrations and use sampling for full event retention when volume spikes.- As a full-stack dev I’d implement client SDKs (JS/Node) to enforce schema, redaction, and sign logs before sending to collectors.

HardSystem Design

62 practiced

Design an authorization service for a globally distributed microservices architecture which must handle hundreds of thousands of requests per second with low latency. Include decisions on token format (JWT vs reference tokens), enforcement placement (gateway, sidecar, in-service), replication and key management across regions, permission change propagation, and failover strategies that preserve availability and security.

Sample Answer

**Clarify requirements**- Global multi-region, hundreds of K RPS, low latency, strong consistency for auth decisions when permissions change quickly, resilient.

**High-level approach**- Hybrid tokens: use short-lived signed JWTs for fast, offline validation (stateless), and opaque reference tokens for high-sensitivity flows (revocation/real-time policy changes). JWT TTL = 1–5 mins; use refresh/token introspection for long sessions.

**Enforcement placement**- Primary enforcement at edge API Gateway for coarse-grain auth (route, scope). Deploy sidecar authorization (Envoy + WASM / OPA) per service for fine-grain checks and additional context (user, request body). Services perform final in-process checks for business-critical invariants.

**Key management & replication**- Central KMS (cloud HSM) with region-replicated read-only signing keys. Use active-primary for signing in preferred region, replicate public keys via JWKS endpoints and CDN with short cache TTL. Rotate keys with overlapping validity windows and automatic JWKS discovery.

**Permission change propagation**- Strong-change paths: immediate revocation via distributed cache (Redis/KeyDB with geo-replication) + push notifications to sidecars via message bus (Kafka/RabbitMQ). For JWTs, revoke by maintaining blacklist with key-versioning; use short TTL to bound exposure.

**Failover & availability**- Gateways and sidecars cache JWKS and permission snippets for short TTL; operate in read-only degraded mode if control plane unavailable. Fall back to safe-deny for high-risk endpoints, safe-allow for low-risk with audit logging. Health-checked multi-region control plane, automatic promotion, circuit breakers to avoid cascading failures.

**Operational notes**- Monitor latencies, cache hit rates, revocation lag; test chaos scenarios. Implement centralized audit events (immutable store) and rate-limit auth endpoints to protect control plane.

This design balances latency (JWT + caching), real-time control (reference tokens + revocation), and global resilience appropriate for full-stack ownership.

HardTechnical

82 practiced

Perform a detailed threat model for your authorization layer using STRIDE: identify threats such as token theft, replay, impersonation, privilege escalation, CSRF, SSRF, insider misuse; map attack paths and trust boundaries; assign risk levels and propose mitigations. For each mitigation propose measurable KPIs and alerting thresholds to detect exploitation.

Sample Answer

**Overview & scope**Threat model covers web app authorization layer: session/jwt tokens, OAuth/OIDC flows, RBAC/ABAC logic, cookies, API gateway, backend services, database. Trust boundaries: browser ↔ frontend, frontend ↔ API gateway, gateway ↔ auth service (token introspection), service ↔ database, 3rd-party IdP.

**STRIDE mapping, attack paths & risk**- Spoofing / Impersonation (High): stolen JWTs or OAuth codes via XSS, phishing. Path: attacker exfiltrates token from browser → calls API.- Tampering (Medium): manipulated tokens or role claims. Path: client modifies token if not signed/validated.- Repudiation (Medium): insufficient logging allows denial of malicious act.- Info disclosure / Token theft (High): access_token in localStorage, long expiry. Path: XSS → read storage.- DoS/Resource abuse (Medium): token replay / brute-force refresh tokens.- Elevation of privilege (High): RBAC misconfiguration or insecure direct object references (IDOR).- CSRF (Medium): state-changing actions via forged requests using session cookies.- SSRF (Low-Medium): server-side URL fetch using user input exposing internal services.- Insider misuse (Medium): privileged admin console abuse.

**Mitigations + KPIs & alert thresholds**- Store tokens in httpOnly, Secure SameSite=strict cookies; avoid localStorage. KPI: % of responses setting httpOnly token cookies = 100%; alert if <100% in deploy.- Short-lived access tokens (5–15m) + rotating refresh tokens with revocation list. KPI: median token lifetime <= 15m; alert if >20m.- Strong JWT validation (signature, aud/iss/exp/nbf), reject alg=none. KPI: % tokens failing validation = 0; alert if >0 over 1h.- Use CSRF tokens for stateful flows or SameSite cookies. KPI: CSRF token validation failure rate; alert if >0.1% of requests.- Protect against XSS: CSP, input/output encoding, framework built-ins. KPI: weekly SAST/DAST findings; alert on any high-severity XSS.- RBAC with least privilege, centralized auth middleware, attribute checks server-side. KPI: number of endpoints with server-side role checks = 100%; alert if new endpoint without check detected.- Token reuse/replay detection: store nonce/unique jti, block reuse. KPI: token replay attempts; alert if >5 per hour.- Monitor anomalous use: geo/IP velocity, device fingerprinting, brute-force. KPI/alert: >3 distinct countries for same user in 1h; >10 failed refresh attempts from IP in 10m.- SSRF hardening: allowlist egress, timeout, max redirects. KPI: blocked outbound requests to private ranges; alert on any allowlist bypass attempt.- Audit & insider controls: MFA for admin, immutable logs, separation of duties. KPI: admin actions requiring MFA = 100%; alert if admin action without MFA.

**Detection & logging**- Centralized auth logs (successful/failed token exchange, revocations, jti reuse, role-change). Alerting: high-severity events (token replay, mass failures, unusual geolocation) to on-call within 5m.

**Trade-offs**Balance UX: shorter tokens increase refresh traffic — mitigate with silent refresh + refresh-rate limits. Prioritize cookie-based tokens and server-side checks for full-stack apps.

MediumTechnical

64 practiced

Design a testing strategy to ensure authorization correctness in CI/CD: include unit tests for policy logic, integration tests that simulate roles and permissions, contract tests between services, end-to-end UI tests that assert both allow and deny cases, and negative tests that prove certain users cannot perform actions. Explain how to maintain test suites when policies evolve.

MediumTechnical

64 practiced

You must implement multi-tenant RBAC where each tenant has its own roles and tenant-specific admins, while platform staff have global admin roles. Design the permission model and database layout that supports tenant isolation, role inheritance, and cross-tenant support for platform operators. Explain how to enforce checks at runtime and how to migrate existing single-tenant roles.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.