Security, Multitenancy, And Authorization

What's being tested

Microsoft system design interviews often probe whether a Software Engineer can build systems that are correct under untrusted clients, shared infrastructure, and fine-grained permissions. The interviewer is looking for practical judgment: how you authenticate callers, authorize actions, isolate tenants, log sensitive operations, and prevent common abuse without overengineering. For services like cloud consoles, image storage, notification systems, and AI APIs, security is not a bolt-on feature; it shapes the API contract, data model, cache keys, request flow, observability, and failure modes. A strong answer shows you can reason about least privilege, scoped access, token lifecycle, and defense in depth while still delivering a scalable service.

Core knowledge

• Authentication answers “who is calling?” and is usually delegated to an identity provider using OAuth 2.0 and OpenID Connect. In a Microsoft-style environment, expect tokens issued by Microsoft Entra ID, with claims like sub, tid, aud, iss, exp, scp, and roles.

• Authorization answers “is this caller allowed to do this action on this resource?” Model it explicitly as allow(subject, action, resource, context). Do not rely only on frontend hiding; every backend endpoint must enforce authorization at the service boundary.

• RBAC works well for coarse permissions such as Owner, Reader, or Contributor, but it becomes awkward for resource-specific conditions. ABAC adds attributes like tenant, region, data classification, device trust, or request source, while ACLs are useful for object-level sharing such as image ownership or per-file permissions.

• Tenant isolation must exist in both compute and data paths. At minimum, every row or object should include tenant_id, every query should filter by it, every cache key should include it, and every async job should carry it. Stronger isolation uses separate databases, storage accounts, keys, or clusters per tenant.

• Authorization enforcement points should be close to the protected resource. A typical pattern is PEP/PDP: the API gateway or service acts as the Policy Enforcement Point, while a policy service such as Open Policy Agent or an internal authorization service acts as the Policy Decision Point.

• JWT validation is local and fast but easy to get wrong. Validate iss, aud, exp, nbf, signature algorithm, key ID kid, and token type; cache JWKS keys with TTL; reject unsigned tokens and algorithm confusion. Never treat decoded claims as trustworthy before signature validation.

• Token lifecycle matters for secure APIs. Short-lived access tokens, refresh tokens with rotation, revocation for high-risk events, and scoped tokens reduce blast radius. For upload/download systems, prefer short-lived pre-signed URLs over routing all bytes through the app server.

• Least privilege should drive scope design. A notification scheduler may need notifications.send for one tenant, not global database access; an image processor needs read/write to a specific object prefix; a Copilot plugin should receive a delegated token scoped to the user’s allowed resources.

• Confused deputy risks appear when Service A uses its broad privileges to access Service B on behalf of a user. Carry user and tenant context through internal calls, distinguish application permissions from delegated permissions, and require downstream services to re-check effective permissions.

• Audit logging should record security-relevant decisions, not just requests. Include request_id, actor_id, tenant_id, resource_id, action, decision allow/deny, policy version, source IP, user agent, and timestamp. Logs must be tamper-resistant and avoid storing secrets or full access tokens.

• Rate limiting and abuse controls should be multi-dimensional: key by tenant_id, user_id, IP, API key, and endpoint. Token bucket capacity is roughly burst_size, refill rate is r requests/sec, and allowed traffic over time t is bounded by burst_size + r t.

• Secure defaults reduce operational mistakes. Deny by default, fail closed for authorization errors, encrypt data at rest and in transit, use envelope encryption with per-tenant keys where appropriate, separate public and private object namespaces, and ensure background jobs cannot bypass policy checks.

Worked example

For Design a Secure Copilot API, a strong candidate would start by clarifying: “Who calls this API — first-party apps, third-party apps, or both? Does the Copilot act on the user’s data, tenant data, or public data? Are responses allowed to contain sensitive enterprise content?” Then they would state assumptions: multi-tenant enterprise customers, Microsoft Entra ID authentication, delegated user access, and strict tenant data isolation.

The answer can be organized around four pillars: request flow, authorization model, data isolation, and abuse mitigation. In the request flow, the client obtains an access token from the identity provider, sends it to the API gateway, the gateway validates token shape and rate limits, and the Copilot service performs resource-level authorization before retrieval or action execution. In the authorization model, distinguish user-delegated actions like “summarize my documents” from app-only actions like “index tenant content,” because the latter needs explicit admin consent and narrower scopes.

For data isolation, every retrieval query, vector search, cache entry, prompt context, and audit event must include tenant_id; otherwise a shared embedding index or response cache can leak data across tenants. A key design decision is whether to use one shared vector index with tenant filters or separate indexes per tenant: shared is cheaper and easier to operate, but separate indexes provide stronger isolation for large or regulated tenants. For threat mitigation, discuss replay protection through TLS, short token TTLs, nonce or request signing for high-risk calls, prompt injection defenses around tool execution, and output filtering for unauthorized content. Close by saying that, with more time, you would add policy versioning, red-team test cases, incident response hooks, and tenant-level compliance controls such as customer-managed keys.

A second angle

For Design a cloud console main page, the same security concepts apply, but the user experience makes authorization more visible. The page should not fetch “all resources then hide forbidden ones”; each backend query should return only resources the user can view, scoped by tenant, subscription, project, or resource group. The design needs fast permission checks because the console may render dozens of widgets, so you can cache effective permissions with short TTLs and invalidate on role changes. Unlike a Copilot API, the main risk is often stale or inconsistent authorization across many microservices: one card may say the user has access while another service denies the click-through. A strong answer emphasizes a consistent policy model, graceful partial rendering, audit logs for administrative actions, and clear handling of cross-tenant account switching.

Common pitfalls

Pitfall: Treating authentication as authorization.

A tempting but weak answer is “the user has a valid JWT, so they can call the API.” A better answer validates the token first, then checks whether the subject has the required action on the specific resource under the current tenant and context.

Pitfall: Ignoring tenant context in caches, queues, and background workers.

Candidates often remember tenant_id in database tables but forget it in Redis keys, CDN paths, object storage prefixes, scheduled notification jobs, or image-processing events. In multi-tenant systems, every async boundary must propagate tenant and actor context, or the system can leak data even if the synchronous API looks correct.

Pitfall: Communicating security as a checklist instead of a request flow.

Saying “use encryption, RBAC, rate limiting, logging” sounds generic. It lands better to walk one concrete request end to end: token issuance, gateway validation, service-level policy check, data access with tenant filter, response redaction, audit event, and failure behavior.

Connections

Interviewers may pivot from this area into API gateway design, distributed caching, object storage security, rate limiting, audit log pipelines, or zero-trust service-to-service communication. For AI-flavored systems, expect follow-ups on secure retrieval, prompt injection, tool permissions, and preventing cross-tenant leakage through caches or embeddings.

Further reading

• OWASP API Security Top 10 — practical taxonomy of broken object-level authorization, excessive data exposure, token misuse, and abuse patterns.

• NIST SP 800-63B: Digital Identity Guidelines — authoritative guidance on authentication, session management, authenticators, and token handling.

• Google BeyondCorp: A New Approach to Enterprise Security — foundational zero-trust model useful for reasoning about internal service access and device/user context.