What should I use for authorization in a multi-tenant SaaS product?

For a multi-tenant SaaS, the best authorization approach is usually:

1) Use RBAC + tenant scoping as the default

Start with:

• Tenant isolation: every request is evaluated in the context of a tenant
• Roles: e.g. owner, admin, member, billing, viewer
• Permissions: fine-grained actions like invoice:read, project:write

This is the most common and practical model because it’s simple to reason about and scales well for most products.

Example

A user may be:

• admin in Tenant A
• viewer in Tenant B

Authorization always checks:

1. Which tenant is this request for?
2. What role does this user have in that tenant?
3. Does that role allow this action?

---

2) Add ABAC for resource-level rules when needed

If your product has more complex rules, supplement RBAC with attribute-based access control such as:

• user department
• resource ownership
• resource status
• plan tier
• region/data residency

Example

• Only users in the same tenant and same department can edit a record
• Only the record owner can delete it unless they are an admin

This is useful for object-level permissions, but don’t start with it unless you need it.

---

3) Use a policy engine if authorization gets complex

If you expect lots of rules, consider a centralized policy engine like:

• OPA (Open Policy Agent)
• Casbin
• SpiceDB / Zanzibar-style relationship-based auth for very large, graph-like permission systems

These help when you have:

• many services
• many permission rules
• inheritance/shared resources
• team/project/document relationships

---

4) Enforce tenant isolation at multiple layers

Do not rely only on application logic.

Best practice:

• Include tenant_id on all tenant-owned records
• Filter every query by tenant_id
• Use database-level protections when possible:
  • Row-Level Security (RLS) in Postgres is excellent
• Never trust tenant IDs from the client without validating the user’s membership

---

5) Recommended default architecture

For most SaaS products:

• Authentication: OIDC/OAuth/SAML or email/password + MFA
• Authorization:
  • Tenant membership
  • Role-based permissions
  • Resource ownership checks
• Data protection:
  • DB scoping by tenant_id
  • Optional Postgres RLS
• Admin overrides:
  • Super-admin separate from tenant admins
  • Strong audit logging

---

Practical recommendation

If you’re building an early-stage or mid-sized SaaS:

Use RBAC with tenant-scoped memberships, and add ABAC/object-level checks only where needed.

That gives you:

• simplicity
• clear mental model
• strong tenant isolation
• room to grow

---

A simple rule of thumb

• Small/medium SaaS → RBAC + tenant scoping
• Complex business rules → RBAC + ABAC
• Highly connected/shared resources at scale → relationship-based auth / policy engine

If you want, I can also suggest a concrete schema for users, tenants, roles, and permissions, or recommend a stack for your specific tech setup.