Enterprise SSO for Multi-Tenant SaaS: SAML, OIDC and SCIM

Enterprise single sign-on lets a customer's employees log in to your product using the identity provider their company already runs — Okta, Microsoft Entra ID, Google Workspace, Ping, or something older and stranger — instead of a username and password you store.

That definition makes it sound like an integration. In a single-tenant application it mostly is. In a multi-tenant SaaS product it's an architectural commitment, and the gap between those two things is where a lot of first enterprise deals go sideways.

This post assumes you've already made the tenancy decisions underneath. If you haven't, start with multi-tenant SaaS architecture — authentication inherits almost everything from how tenancy was modeled, and reading these in the other order means reading this one twice.

Why enterprise SSO isn't one connection

When a founder says "we added SSO," they usually mean they added a Google or Microsoft login button. That's social login dressed in enterprise clothing. It authenticates a person. It doesn't satisfy an enterprise.

What an enterprise buyer is actually asking for is this: our identity provider is the only system allowed to decide who our employees are, and your product has to accept that decision for our users and nobody else's.

Read that again, because the second half is the architecture. For our users and nobody else's. Each tenant gets its own trust relationship with its own identity provider, and those relationships have to stay separate from each other.

In practice, every SSO-enabled tenant arrives with its own:

• Identity provider, with its own metadata endpoint or uploaded XML
• Signing certificate, which expires on a schedule you don't control
• Attribute names — one sends email, the next sends emailAddress, the third sends a non-standard URN and expects you to cope
• Group or role claims that have to map onto your permission model
• Protocol preference, which is not negotiable from their side

Ten enterprise customers means ten of those, live at the same time, configured differently, failing independently. The thing you're building isn't an SSO integration. It's a small identity federation service with a configuration store behind it.

Everything else in this post follows from that one sentence.

Tenant discovery: the step before login

Here's the problem nobody warns you about. To route a user to the right identity provider, you need to know which tenant they belong to. But you can't know that from a session, because they don't have one yet — they haven't logged in. That's the whole point.

So you need a way to resolve tenant from almost nothing. There are three workable approaches, and the one you pick shapes your login page for years.

1. Email domain matching

The user types an email address. You match the domain against a table of domains claimed by tenants, then redirect to that tenant's identity provider.

This is the pattern most enterprise products converge on, because it asks the user for one thing they already know. It also carries the sharpest edge in the whole topic: domain claims have to be verified. If any tenant can assert @acmecorp.com without proving control of it, you've built a way for one customer to intercept another customer's logins. Verify by DNS TXT record, the same way every other service does, and treat an unverified claim as no claim.

Watch for contractors and subsidiaries too. A single person may legitimately belong to two tenants on one email address, and a design that assumes one domain maps to one tenant will eventually be wrong.

2. Subdomain or vanity URL

Each tenant gets acme.yourproduct.com, and the hostname resolves the tenant before any user input at all.

Cleanest option technically, and the friendliest for the user who bookmarks it. The cost is operational: wildcard DNS, wildcard or automated certificate issuance, and a routing layer that resolves tenant from the host header on every request. If you're already using subdomains for tenant isolation, this is almost free. If you aren't, it's a platform change rather than an auth feature.

3. Explicit tenant picker

The user types an organization name or code.

Worst user experience, occasionally the only honest answer — particularly for consultancies and agencies whose staff genuinely work across several tenants on a personal email address.

What to do

Most products should implement email domain matching with verified claims, and treat subdomains as a later addition rather than a prerequisite. The decision worth getting right now is narrower than it looks:

Store the mapping in a dedicated table, resolved at request time, with no tenant identifier ever read from user-supplied input other than through that lookup. That single constraint is what stops tenant discovery becoming tenant selection, which is a very different and much worse feature.

SAML 2.0 and OIDC — you need both

The question teams ask is "SAML or OIDC?" The answer for anything selling to enterprises is "both," and the reason is commercial rather than technical.

SAML 2.0 is an OASIS standard that has been in production since 2005. It's XML, it's browser-redirect based, and it is deeply embedded in large organizations. If you sell to banks, insurers, healthcare systems, universities or government, you will be asked for SAML, and "we support OIDC instead" will not be accepted as an answer. It will be recorded as a gap.

OpenID Connect is an identity layer on top of OAuth 2.0. It's JSON, it uses signed JWTs, it has far better support for native mobile and single-page applications, and newer identity platforms lead with it. It's also considerably less painful to implement correctly.

A warning on the last row, because it's where custom SAML implementations go wrong. XML signature validation has a long history of bypass vulnerabilities, most of them caused by validating the signature and then reading the assertion separately, so that an attacker can supply one document that gets validated and a different one that gets trusted. Use a maintained library for your platform, pin the expected issuer and audience, enforce assertion expiry and replay protection, and do not write your own XML canonicalization. This is not a good place to be original.

Practical sequencing: build OIDC first, then SAML. OIDC gets you working SSO sooner and teaches your team the tenant-routing problem on the easier protocol. Then add SAML before your first enterprise security review, because that's when it stops being optional.

JIT provisioning versus SCIM

SSO answers "can this person log in." It says nothing about who exists, what they can do, or what happens when they leave. That's provisioning, and enterprise buyers care about it more than they care about your login page.

Just-in-time provisioning

The user authenticates, you don't recognize them, so you create the account from the attributes in the assertion. Cheap to build, works immediately, and it's the right first step.

It has one hole, and it's the hole every security questionnaire aims at: deprovisioning. An employee is removed from the customer's identity provider on Friday afternoon. With JIT alone, their account in your product still exists on Monday. They can't log in through SSO any more — but the account is live, any API tokens they hold still work, and if you ever allowed a password fallback, so does that.

"Their account is disabled in our IdP" is not the answer the customer's security team wants. They want the account gone from your system, and they want to not have to ask.

SCIM

SCIM — System for Cross-domain Identity Management — is the standard that lets the customer's identity provider push user and group changes into your product automatically. It's specified in two IETF documents: RFC 7643 for the core schema and RFC 7644 for the protocol.

In practice you implement a REST API that the IdP calls. The protocol defines /Users and /Groups resource endpoints supporting GET, POST, PUT, PATCH and DELETE, plus discovery endpoints — /ServiceProviderConfig, /ResourceTypes and /Schemas — that tell the IdP what you actually support.

Four things make a SCIM implementation harder than it reads:

It has to be tenant-scoped. Every SCIM credential belongs to exactly one tenant, and every resource it touches must be checked against that tenant. A SCIM endpoint is a write API handed to an outside system, which makes a missing tenant check here worse than almost anywhere else in your product.

PATCH is genuinely fiddly. Partial update operations arrive in a path syntax that is not intuitive, and different identity providers emit different shapes for the same logical change. Expect to test against each one you support rather than assuming conformance.

Deletion needs a defined meaning. Most providers soft-delete by setting active: false rather than issuing DELETE. Decide what that means in your product — revoke sessions, invalidate tokens, retain data for the tenant admin — and write it down, because the customer will ask.

Group sync touches your permission model. If groups map to roles, the customer's IdP is now editing your authorization data. That boundary has to be explicit in your back-end architecture, not emergent.

The sequence that works

Ship JIT provisioning with your first SSO release. Add SCIM when a deal requires it, which in our experience is the second or third enterprise customer rather than the first. Build JIT so that SCIM slots in alongside it rather than replacing it — same user records, same tenant scoping, different write path.

Per-tenant IdP configuration, without a deploy

Here's the test for whether your SSO is actually multi-tenant. Can you onboard a new enterprise customer's identity provider without a code change, a config file edit, or a restart?

If the answer is no, you don't have multi-tenant SSO. You have an SSO integration that you will be redeploying every time you win a deal, which is a strange thing to have made your sales cycle depend on.

Getting to yes means IdP configuration lives in your data model, per tenant, and is editable by someone who isn't an engineer. Each tenant's connection record carries its protocol, its endpoints, its certificate or JWKS URL, its attribute mapping, and its group-to-role mapping.

Three operational details decide whether this holds up in production:

Certificate expiry will take a customer offline. SAML signing certificates expire, the customer's IT team rotates them without telling you, and every login for that tenant fails at once. Store the expiry date, alert on it ahead of time, and support two active certificates during a rotation window. This is the single most common cause of an SSO outage, and it's entirely preventable.

Self-serve setup needs a test mode. Let the tenant admin configure and validate a connection before it becomes mandatory for their whole organization. Without that, the first time a misconfiguration surfaces is when four hundred people can't log in.

Keep a documented break-glass path. When a tenant's IdP is down — and it will be — somebody needs a way in. An emergency local account for named tenant admins, heavily logged and separately alerted, is better than the alternative, which is a support ticket during an incident and an engineer editing production data under pressure.

The failure mode that actually hurts

Broken logins are loud, annoying and quickly fixed. They aren't the risk.

The risk is this: a validly authenticated user from tenant A gets served tenant B's data.

It happens because authentication and authorization get conflated. The token is real. The signature checks out. The issuer is trusted — for some tenant. What's missing is the check that this user's tenant matches the tenant that owns the record being read.

Three paths lead there, and all three pass a happy-path test suite:

Tenant trusted from the request. A tenant identifier taken from a header, a query parameter or a JWT claim the client can influence, and then used in a query without being checked against the authenticated session's tenant. The user changes one value and crosses a boundary.

Issuer trusted globally instead of per tenant. You validate that a token came from a configured identity provider, but not that it came from this tenant's identity provider. Two tenants using the same IdP vendor — which is extremely common, since most enterprises use one of four — and the boundary is gone.

A query path that forgot the tenant filter. Usually a report, a bulk export, an admin screen or a background job — somewhere written later, by someone who assumed the filter happened upstream.

Three defenses, in order of how much they're worth:

1. Enforce tenant scoping below the application layer. Row-level security in the database, or a repository layer no query can bypass. Relying on every developer to remember a WHERE tenant_id clause forever is not a control — it's an expectation.
2. Bind the issuer to the tenant. Validate the token's issuer against the specific connection record for that tenant, not against a list of all known issuers.
3. Test for it deliberately. Write the negative test. Authenticate as tenant A, request tenant B's resource by ID, assert a 404. Run it on every endpoint, in CI, forever. Nobody finds this bug by accident, and the people who find it in production are rarely friendly about it.

Build or buy: the honest threshold

Almost everything written about enterprise SSO is published by companies selling enterprise SSO, which means the conclusion is decided before the article starts. We don't sell an auth platform, so here's the version with the trade-off left in.

Buy when:

• You have fewer than roughly twenty enterprise customers needing SSO
• SSO is blocking a deal this quarter and the deal won't wait a sprint cycle
• Your team has no identity expertise and no appetite for acquiring it under deadline
• You need SAML and OIDC and SCIM all at once, which is the usual way this arrives

Consider building when:

• SSO-enabled tenants are into the dozens and per-connection vendor pricing has become a visible line item
• Your tenancy model already makes per-tenant configuration natural rather than bolted on
• You need authorization logic the vendor's model doesn't express
• Identity is close enough to your product's core that outsourcing it constrains the roadmap

The honest version of the economics: a vendor charges per connection, so the cost scales with your enterprise success. Building is a fixed engineering investment plus a permanent maintenance obligation — certificate rotation, IdP quirks, protocol updates, the next signature bypass advisory. The crossover isn't a number we can give you without knowing your deal size and your vendor's pricing, but it's further out than engineering teams estimate and closer in than vendors imply.

One recommendation regardless of which way you go: keep the boundary clean. Put your own interface in front of whichever provider you use, so authentication and tenant resolution are yours and the provider is an implementation detail. Teams that wire a vendor's SDK straight through their application find that the decision has quietly become permanent — not because building was hard, but because unpicking it later touches everything.

That's the same reasoning as any other build versus buy decision: the question is rarely which option is better today, it's which one you can reverse.

Frequently asked questions

What's the difference between SAML and OIDC for enterprise SSO?

SAML 2.0 is an older XML-based standard that moves signed assertions through browser redirects; OpenID Connect is a JSON and JWT layer on top of OAuth 2.0. OIDC is easier to implement, handles native and mobile apps properly, and rotates signing keys automatically through a JWKS endpoint. SAML is what large regulated enterprises still run and still ask for by name. The difference that matters commercially is not technical quality — it's which one your buyer's IT team already supports.

Do we really need both SAML and OIDC?

If you sell to enterprises, yes. Newer identity platforms lead with OIDC, but banks, insurers, healthcare systems, universities and government bodies run SAML 2.0 and will record "OIDC only" as a gap in a security review rather than an acceptable alternative. Build OIDC first because it's faster to get right, then add SAML before your first enterprise security questionnaire.

What is SCIM provisioning, and do we need it?

SCIM is an IETF standard — RFC 7643 and RFC 7644 — that lets a customer's identity provider push user and group changes into your product automatically, so accounts are created, updated and deactivated without anyone asking you. You need it the moment deprovisioning becomes a contractual question, which is usually your second or third enterprise customer. Just-in-time provisioning covers account creation, but it leaves departed employees with live accounts in your system, and that is precisely what a security questionnaire asks about.

How do we route a user to the right identity provider?

That's tenant discovery, and it has to happen before authentication because the user has no session yet. Three approaches work: matching the domain of the email address they type against verified tenant domain claims, resolving the tenant from a subdomain, or asking for an organization code. Most products should use verified email domain matching. The non-negotiable part is verification — an unverified domain claim lets one customer intercept another customer's logins.

Should we build enterprise SSO or buy an auth platform?

Our rule of thumb is to buy below roughly twenty SSO-enabled enterprise customers and to consider building above that, and only if your architecture already treats per-tenant configuration as normal. A vendor's cost scales with your enterprise success; building is a fixed investment plus permanent maintenance — certificates, identity provider quirks, protocol changes. Whichever you choose, put your own interface in front of it so the provider stays replaceable.

How long does it take to add enterprise SSO to a multi-tenant SaaS product?

It depends almost entirely on whether your tenancy model already supports per-tenant configuration. Where it does, OIDC with just-in-time provisioning is a contained piece of work and SAML plus SCIM follow as separate increments. Where tenancy is implicit in the code, the SSO work is the smaller half of the job — the larger half is making tenants first-class, and that is a scoping conversation rather than a sprint. We'd rather tell you which situation you're in after looking at the codebase than guess from a feature list.