Designing Auth for Multi-Tenant SaaS

The Multi-Tenancy Challenge

In a multi-tenant SaaS application, you need to ensure that users from Tenant A can never access Tenant B's data - even if there's a bug in your application code.

Tenant Isolation Strategies

Database-Level Isolation

The most secure approach: separate databases per tenant. Expensive, but eliminates cross-tenant data leakage at the infrastructure level.

Schema-Level Isolation

One database, separate schemas per tenant. Good balance of isolation and cost for PostgreSQL users.

Row-Level Security

All tenants in one schema, with row-level security policies. Most cost-effective, but requires careful implementation.

-- PostgreSQL RLS policy
CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Token Design for Multi-Tenancy

Your JWT should include tenant context:

{
  "sub": "user_123",
  "tenant_id": "tenant_456",
  "roles": ["admin"],
  "permissions": ["read:documents", "write:documents"]
}

Always validate the tenant_id claim against the resource being accessed.

Cross-Tenant Access

Sometimes users need access to multiple tenants (agencies, consultants). Design for this from the start:

// User can have multiple tenant memberships
const memberships = await getUserTenants(userId);
const activeTenant = memberships.find(m => m.tenantId === requestedTenant);

if (!activeTenant) {
  throw new ForbiddenError("No access to this tenant");
}

Tenant-Specific Identity Providers

Enterprise tenants often want their own SSO. Your auth system should support:

• Per-tenant SAML/OIDC configuration
• Tenant discovery from email domain
• Fallback to your default IdP

Get multi-tenant auth right, and you have the foundation for enterprise sales.