Multi-Tenant SaaS Architecture: Databases, Organisations, Permissions and SSO

How do I handle authentication, organizations, permissions and single sign-on in a modern SaaS?

Buy authentication from a provider rather than building it, but keep organisations, memberships and roles in your own database so your authorisation logic is yours. Start with a small set of roles checked on the server on every request, and move towards attribute- or relationship-based rules as permissions get finer. Add SAML or OIDC single sign-on, SCIM provisioning and audit logs when your first enterprise customers ask, and design the data model so adding them later is not a rewrite.

Authentication: build or buy?

Authentication is security-critical, full of edge cases (password resets, email verification, MFA, session revocation, account linking) and rarely a differentiator. In our view almost every SaaS should buy it. The question is which kind of provider: Our guide to what not to build in a SaaS applies the same build-or-buy test to email, billing and analytics.

WorkOS, for example, documents SSO over SAML and OIDC, Directory Sync over SCIM, audit logs, RBAC and an admin portal that customer IT teams use to set up their own connections. Clerk documents organisations with default admin and member roles, custom roles and permissions, invitations, verified domains and enterprise connections over SAML or OIDC. Compare them on the enterprise features you will need in a year, not just sign-up screens.

The organisation data model

Even if your auth provider has an organisations feature, mirror the core of it in your own database so you can join against it, enforce it in RLS and migrate providers later. A minimal model:

• users: your user ID plus the provider's user ID and email.
• organizations: the tenant; id, name, plan, billing customer ID, data region, SSO settings.
• memberships: organization_id, user_id, role, status. A user can belong to several organisations; the active one is chosen per session.
• invitations: email, organisation, role, token, expiry, inviter.
• domains: verified email domains for auto-join or SSO enforcement.
• audit_events: who did what, to which resource, in which organisation, when and from where.

Permissions: RBAC, then finer rules

Role-based access control (RBAC) maps users to roles such as owner, admin, member and viewer, and roles to permissions. It is easy to explain to customers and enough for most products at launch. Its limits appear when rules depend on attributes ("editors can publish only in their own department") or relationships ("anyone the document is shared with can comment"). The OWASP Authorization Cheat Sheet goes further than many teams expect: it says attribute-based and relationship-based access control (ABAC and ReBAC) should typically be preferred over RBAC for application development, because they handle fine-grained and contextual rules better.

A pragmatic path is to define permissions as named actions (invoice.read, project.delete) from day one, map roles to them, and check permissions, not role names, in code. That lets you add resource-level or attribute rules later without touching every check. Whatever model you choose, OWASP's core rules apply:

• Deny by default: access needs an explicit grant.
• Check on every request, on the server: OWASP says developers must never rely on client-side access control checks; hiding a button is not authorisation.
• Check the specific object: confirm the record belongs to the caller's organisation, not just that the caller is logged in, to prevent insecure direct object references.
• Apply least privilege and review role assignments over time.
• Test authorisation with automated tests that try cross-tenant access.

Single sign-on and SCIM

Enterprise buyers usually ask for SSO so their staff sign in through the company identity provider. The two protocols you will meet are SAML 2.0 and OpenID Connect (OIDC); supporting both through your auth provider covers most identity providers. Implementation points that save support time:

1. Model SSO connections per organisation, linked to verified domains.
2. Decide whether SSO is optional or enforced for an organisation, and what happens to existing password users.
3. Map identity-provider groups or attributes to your roles, with a safe default role.
4. Give customer admins a self-serve setup flow; vendor admin portals exist for this reason.
5. Add SCIM when customers want automatic provisioning and, more importantly, deprovisioning. SCIM is defined by IETF RFC 7644 as a protocol for creating, reading, updating and deleting identity records across organisational boundaries. When someone leaves the customer's company, SCIM removes their access to your product without anyone remembering to do it.

Audit logs

Security questionnaires almost always ask for audit logs, and OWASP describes logging as one of the most important detective controls. Record sign-ins, failed sign-ins, role and membership changes, SSO configuration changes, data exports, deletions and billing changes, with actor, organisation, target, timestamp and IP. Make the log append-only, keep it for a defined period, and let organisation admins view or export their own events. Our guide to security questionnaires and SOC 2 explains what buyers typically ask for.

What to build when

If you want help designing or implementing this, our B2B SaaS development service covers tenancy, permissions and SSO. If your product is early and your provider already handles organisations and roles well, you may not need custom work yet; follow the MVP row above and revisit at the first enterprise deal.