Multi-Tenant SaaS Authorization

B2B SaaS authorization has one non-negotiable requirement: tenant isolation.

Your authorization model must ensure a request for tenant A can never access data for tenant B, even when developers make mistakes.

Core design questions

What is a tenant?

Common shapes:

• Org / Workspace model (Slack, Notion)
• Account / Customer model (billing-centric)
• Project model nested under org

Pick one canonical “top” boundary and make everything hang off it.

How do invites and membership work?

Model:

• invitations (pending state)
• acceptance
• membership roles
• offboarding

Keep “who can invite” tightly controlled.

Common patterns

Scoped roles

• org_admin
• org_billing_admin
• project_admin

ReBAC for sharing

Use relationships for:

• sharing a document with a user
• granting access via groups
• “inherited” access through membership

Default-deny

Explicitly design for:

• new tenants
• new resources
• deactivated users

Pitfalls

• Putting tenantId only in the UI layer (must be enforced server-side).
• “God mode” internal tools without audit.
• Overusing “org_admin” to paper over missing model decisions.

Where to go next

• /topic/authorization/fine-grained-authorization-zanzibar
• /topic/authorization/data-layer-authorization-row-level-security
• IDPro Book of Knowledge (reference): https://bok.idpro.org/