The Complete SaaS Cookbook, Part 2: Authentication, Authorization & Multi-Tenancy

The Three Pillars

Authentication (who are you?), authorization (what can you do?), and multi-tenancy (whose data can you see?) are the three pillars that every SaaS product must get right. Get them wrong, and you'll spend months retrofitting — or worse, ship a security vulnerability that destroys customer trust.

Authentication: Don't Roll Your Own

This is not the place to be creative. Use a proven solution:

For most SaaS products: Better Auth or NextAuth.js. Both are open-source, TypeScript-native, and handle the complexity of email/password, OAuth providers, magic links, and session management.

For enterprise SaaS: Add SAML/SSO support from day one if your customers are large organizations. This is a deal-breaker for enterprise procurement and painful to retrofit. Auth0 or WorkOS handle this well.

Essential auth features for SaaS

• Email verification: Required. Unverified accounts are a spam vector
• Password reset: Use time-limited, single-use tokens. Never send passwords in email
• Multi-factor authentication: TOTP (authenticator apps) at minimum. Enterprise customers will require it
• Session management: Users should be able to see and revoke active sessions across devices
• Rate limiting: Protect login and registration endpoints from brute force

Authorization: RBAC Done Right

Role-Based Access Control (RBAC) is sufficient for most SaaS products. The typical role hierarchy:

Owner       → Full control, billing, danger zone
Admin       → Team management, settings, all features
Member      → Standard feature access
Viewer      → Read-only access
Guest       → Limited access (shared links, public views)

Implementation rules:

• Permissions, not roles, in your code: Check can('billing.manage'), not role === 'admin'. Roles map to permission sets, but your application logic references permissions. This makes it trivial to add new roles or adjust permissions later
• Middleware, not component-level checks: Enforce authorization at the API/route level, not in UI components. UI should hide unauthorized actions for UX, but the server must enforce them for security
• Resource-level permissions: Beyond role-based access, some resources need owner-level checks ("can this user edit this specific document?"). Plan for this from the start

Multi-Tenancy: Shared Database, Isolated Data

For 95% of SaaS products, the right multi-tenancy strategy is a shared database with a tenant_id column on every tenant-scoped table.

Why not separate databases per tenant?

Separate databases sound clean but create operational nightmares: migrations must run against every database, connection pooling becomes complex, and cross-tenant analytics becomes impossible. Reserve database-per-tenant for regulated industries (healthcare, finance) where data isolation is a compliance requirement.

Implementation pattern

// Middleware: extract tenant from subdomain or header
const tenant = await getTenantFromRequest(req);

// Every query automatically scoped
const projects = await db.project.findMany({
  where: { tenantId: tenant.id }
});

// Row-Level Security in PostgreSQL (belt + suspenders)
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

The critical rule: never trust the client to provide tenant context. Extract it server-side from the authenticated session, subdomain, or JWT claim.

Tenant Onboarding Flow

The typical SaaS tenant setup flow:

1. User signs up (creates user account)
2. User creates organization (creates tenant)
3. System provisions tenant workspace (subdomain, default settings, trial subscription)
4. User invites team members (creates additional user-tenant associations)

Design your data model to support users belonging to multiple tenants from day one. Even if your V1 doesn't need it, retrofitting this is extremely painful.

In Part 3, we tackle the most anxiety-inducing part of SaaS development: billing, subscriptions, and payment integration.