The isolation requirement
In a multi tenant system many customer organizations share the same application and infrastructure. The hard rule is that one tenant must never see or act on another tenant's data, even by accident.
Authorization therefore must answer two questions on every request: which tenant does this caller belong to, and within that tenant what may they do.
Carrying the tenant
The tenant id must travel with every authenticated request, usually as a claim in the token. Every query and every permission check is then scoped by that tenant id. A check that forgets the tenant filter is a classic data leak.
Roles within a tenant
A user's roles are meaningful only inside their tenant. Being an admin in tenant A grants nothing in tenant B. So the policy combines the tenant id with the role to reach a decision.
Defense in depth
- Enforce the tenant filter at the data layer, not just in code paths.
- Validate the tenant claim matches the resource being accessed.
- Log cross tenant attempts as security events.
Key idea
Multi tenant authorization scopes every check by tenant id so roles apply only within a tenant and cross tenant access is structurally blocked.