Multi-Tenant Authorization: Authentication, RBAC, and Isolation

What is multi-tenant authorization?

Multi-tenant authorization determines whether a specific principal may perform a specific action on a specific resource within a specific tenant. A safe decision needs all five parts: principal, tenant, action, resource, and relevant context.

Authentication proves who the principal is. Tenant membership proves which customer organizations that principal belongs to. Authorization decides what the principal may do inside the active tenant. Tenant isolation prevents the request from reaching another tenant's resources, even when the person is otherwise authenticated and has a valid role.

For many B2B SaaS products, a practical starting point is tenant-scoped RBAC: store membership separately from the user, assign roles to that membership, resolve one active tenant per request, scope the resource to that tenant, deny by default, and check permissions in a shared policy layer. Add attributes or resource relationships only when the product has rules that roles cannot express cleanly.

This is a product model as much as a security model. Invitations, team administration, enterprise SSO, service accounts, API keys, plan entitlements, approvals, temporary access, support operations, and offboarding all depend on it.

This guide focuses on identity and access decisions. See the broader multi-tenant architecture guide for pool, silo, and bridge models, and the multi-tenant data architecture guide for database isolation, row-level security, restore, and tenant movement.

Related controls solve different problems

Authentication, authorization, and tenant isolation

A common design mistake is treating a successful login as sufficient protection. AWS explicitly separates these concepts: a person can be authenticated and authorized for an action while the system still applies that action to the wrong tenant.

These controls should reinforce one another. Authorization can reject a cross-tenant resource. Tenant-scoped repositories can make that resource impossible to load. Row-level security can reject the query again. Storage prefixes, queue payloads, cache keys, and audit records can preserve the same tenant boundary.

Resolve context before making the decision

Multi-tenant authorization architecture diagram

The policy decision should receive normalized application facts, not infer a tenant from an untrusted URL or accept a client-supplied role. The application verifies identity, resolves membership and the active tenant, loads the target resource through that tenant, and then requests a decision.

A policy engine can run as a library, a sidecar, a shared service, or a managed authorization system. The product does not need a separate service on day one. It does need one consistent decision contract and clear enforcement boundaries.

Users and tenants have a many-to-many relationship

Model identity, tenants, and memberships separately

A user is a global identity in the product. A tenant is a customer organization or workspace. A membership connects one user to one tenant and holds the status and authorization assignments that apply there.

1. 01

   Use stable identity keys

   Match federated identities by the issuer and immutable subject identifier, not by email address alone. Email addresses can change, aliases can collide, and an identity provider can verify the same address in a different security domain.

2. 02

   Make membership state explicit

   Invited, active, suspended, and removed are different states. A pending invitation should not receive ordinary member access. Suspension should stop new sessions and sensitive operations without destroying the audit trail.

3. 03

   Delegate assignments deliberately

   Most B2B products allow tenant administrators to manage their own members and roles. Protect the rules around owner transfer, last-owner removal, privileged role grants, domain claims, and enterprise provisioning.

4. 04

   Separate workforce and customer administration

   A platform operator is not a tenant administrator. Internal support and operations need their own identities, policies, approval paths, audit events, and constrained tools.

5. 05

   Model workloads as principals

   Service accounts, API clients, agents, integrations, and scheduled processes should receive their own tenant-scoped identities and permissions. Do not make automation impersonate a permanent superuser.

One identity can work in several organizations

Resolve and verify the active tenant

Microsoft's multitenant identity guidance describes two common approaches. The identity system can issue a token containing the selected tenant and role, or the application can keep tokens tenant-agnostic and look up memberships itself. Both can work when the trust boundary is explicit.

Make the active tenant visible in the interface, especially around destructive actions. Server enforcement is essential, but clear context also prevents a legitimate user from changing the wrong organization by mistake.

Use the simplest model that expresses the product

RBAC, ABAC, and relationship-based authorization

NIST defines RBAC around users, roles, permissions, operations, and objects. NIST defines ABAC as evaluating attributes of the subject, object, operation, and sometimes the environment against policy. Google's Zanzibar paper demonstrates a relationship-based model at enormous scale, but most SaaS products do not need Zanzibar's distributed architecture to use relationships as a policy input.

A useful progression is RBAC first, RBAC plus a few explicit resource checks second, and a policy engine or relationship model when repeated rules justify it. Avoid creating a new role for every combination of project, region, approval limit, and feature. That is attribute or relationship data disguised as roles.

Separate policy management, decisions, and enforcement

Design the authorization policy architecture

AWS describes three useful responsibilities: the policy administration point manages policy, the policy decision point evaluates a request, and policy enforcement points apply the decision. These are logical boundaries even when they begin in one application process.

Centralized policy does not mean every request must make a fragile network round trip. A library, sidecar, replicated policy bundle, or service can all preserve the same model. Choose based on latency, consistency, deployment, language, policy ownership, and failure requirements.

Protect operations, not just pages

Place authorization at every enforcement boundary

1. 01

   Map product verbs to explicit actions

   Use stable actions such as project.read, member.invite, invoice.refund, or export.create. Avoid vague checks like is_admin? scattered through controllers, templates, and workers.

2. 02

   Authorize server-side on every request

   OWASP recommends validating permissions on every request and denying by default. Hiding a button improves usability but does not protect the endpoint, GraphQL resolver, file URL, bulk action, or alternate client.

3. 03

   Load resources inside tenant scope

   Prefer tenant.projects.find(id) to a global Project.find(id) followed by a check. Return a response that does not reveal whether an inaccessible cross-tenant resource exists.

4. 04

   Check before the first side effect

   Authorize before writes, emails, webhooks, exports, billing calls, queue publication, or file generation. A later denial cannot undo information already sent or money already moved.

5. 05

   Recheck sensitive state at execution time

   For delayed approvals, jobs, or downloads, do not assume the permission from when work was scheduled remains valid. Re-evaluate current membership, resource state, and policy when the operation executes.

6. 06

   Constrain list and search results

   Authorization is not only a single-record check. Queries, counts, suggestions, search indexes, exports, notifications, and activity feeds must return only resources visible in the active tenant and scope.

7. 07

   Make bulk actions atomic in policy

   Define whether access is all-or-nothing or item-by-item. Never authorize the first record and assume the rest share its tenant, owner, or classification.

Tokens carry claims, not eternal truth

Design tenant-aware sessions and access tokens

A token can carry the principal, issuer, audience, active tenant, role, scope, authentication method, and expiry. Each claim has a lifecycle. A long-lived role claim remains valid after an administrator removes that role unless the system rechecks state or invalidates the token.

Do not place every dynamic resource permission into a large token. It becomes stale, exposes internal structure, increases request size, and makes revocation difficult. Tokens are a good place for stable identity and coarse context; the application or policy system can resolve current fine-grained access.

Permissions change throughout the customer relationship

Plan the multi-tenant authorization lifecycle

The web request is only one execution path

Authorize jobs, integrations, and support access

Platform administration is intentionally cross-tenant, so its failure impact is larger. Keep it on a separate authorization path with stronger authentication, narrower tools, additional monitoring, and no accidental inheritance from customer roles.

Prove denial as rigorously as success

Test and observe multi-tenant access control

1. 01

   Write a permission matrix

   List roles or attributes against product actions and resource scopes. Include ordinary members, tenant administrators, removed users, service accounts, internal support, and unauthenticated requests.

2. 02

   Generate cross-tenant negative tests

   For every protected operation, create the same resource in Tenant A and Tenant B. Confirm that a principal from A cannot read, infer, mutate, export, link, search, or trigger work for B.

3. 03

   Test context changes

   Switch tenants through the same browser session and execution pool. Remove a role while a session is active. Suspend a membership before a queued job runs. Verify that stale state fails safely.

4. 04

   Test every transport

   Cover browser endpoints, public APIs, GraphQL, files, search, webhooks, imports, exports, mobile clients, internal tools, jobs, and service-to-service calls. The least-used path often has the weakest enforcement.

5. 05

   Log useful decision context

   Record principal, tenant, action, resource type and safe identifier, outcome, policy version, enforcement point, and correlation ID. Avoid logging raw tokens or sensitive resource contents.

6. 06

   Alert on suspicious patterns

   Watch repeated cross-tenant denials, privileged role grants, support elevation, new service credentials, policy changes, bulk exports, and sudden permission failures after deployment.

Unit-test policy semantics, integration-test enforcement, and end-to-end test the highest-risk customer journeys. A perfectly tested policy function does not help if an endpoint forgot to call it.

Where authorization boundaries quietly break

Ten multi-tenant authorization failures

Common questions

Multi-tenant authorization FAQ