SAML SSO for Multi-Tenant SaaS: A CIAM Recipe
Updated 2026-08-19 · 9 min read · By @guptadeepak
Key takeaways
- Inbound SSO means your app is the service provider. Each customer brings their IdP. That is the B2B SaaS default.
- One SAML ACS URL with a tenant in the Entity ID beats one ACS per customer.
- Map NameID and groups to your Organization object, not to a global user table.
- JIT provision on first assertion; SCIM to deprovision. SAML alone will not offboard.
- WorkOS, Frontegg, and Auth0 Organizations exist because this recipe is a year of engineering if you build it.
This is the inbound, per-customer SAML recipe for a multi-tenant SaaS. Protocol comparison lives in SAML vs OIDC. Direction lives in inbound vs outbound.
The object model
Store SSO as a property of the Organization, not as a global app setting. Every assertion has to resolve to exactly one tenant before you create or attach a user.
Organization
sso_type: saml | oidc
entity_id
acs_url
idp_metadata_url
nameid_format
role_attribute
Users belong to an Organization. Assertions without a matching Organization fail closed.
ACS design
Give each customer their own assertion consumer service path so you never have to guess the tenant from the SAML Issuer string. A global ACS that sniffs metadata will be a support queue for the rest of the company's life.
Prefer:
https://app.example.com/sso/{org_slug}/acs
over one global ACS that sniffs the Issuer. You will debug the global one for the rest of the company's life.
SP Entity ID should include the org as well, so two customers using Okta Workforce do not collide in metadata.
First-time login
- User hits
/loginand enters work email, or goes through an org-specific SSO URL from the sales engineer. - You resolve Organization. If SSO is required, redirect to the IdP (SP-initiated).
- Assertion returns. Validate signature, audience, recipient, NotOnOrAfter, InResponseTo.
- If the user does not exist, JIT create them in that Organization. Do not JIT into a second org because their email matches.
Deprovisioning
SAML authenticates a person who is still allowed in. It will not tell you the employee left last Friday. SCIM is what removes them. Ship both, or you will fail the security questionnaire on the second enterprise deal.
When to stop building
If you are about to write a metadata upload UI, a signing-cert rotation calendar, and a "test connection" button, look at WorkOS, Frontegg, SSOJet, or Auth0 Organizations. The 60-day SSO playbook assumes you bought one of those.
Build it yourself only if federation is the product.
Related vendors
Auth0
Auth0 remains the safest mid-market default for B2C plus B2B Enterprise SSO when developer velocity matters more than long-run TCO. Auth0 for AI Agents (GA November 2025) and Auth for MCP (GA May 2026) make it the first major CIAM with a packaged agent-identity surface. Below 50k MAU it is still hard to beat. Above 500k MAU, cost and Actions-driven lock-in make FusionAuth, Cognito, or Stytch (Twilio) plus a passkey orchestrator the more honest shortlist.
Clerk
Clerk is the default for native Next.js and Node.js apps under 100k MAU. Drop-in UI is the win. It is not an enterprise CIAM: federation long tail, Java/.NET, FedRAMP, and ISO 27001 are missing or thin. Do not put Clerk on an RFP that needs the rest of the enterprise stack. For that job use Auth0, WorkOS, or SSOJet. For passwordless-native, use MojoAuth or Stytch.
Frontegg
Frontegg is the strongest B2B SaaS CIAM in 2026 by Admin Portal and self-service end-customer experience, the buyer is a SaaS engineering team that needs to ship enterprise-grade IT admin features without building them, and Frontegg delivers more of that out of the box than Auth0 or WorkOS. The trade-off is narrower B2C feature coverage and a smaller ecosystem than Auth0; for B2B-first SaaS the Admin Portal alone often justifies the choice.
SSOJet
SSOJet is a 2026 enterprise-SSO pick for fast-growing B2B SaaS. Public pricing is connection-based and transparent (from $99/month on the public page, no MAU tax). That commercial shape is stronger for companies adding logos quickly than Auth0's MAU curve or a quote-only enterprise IdP. WorkOS remains the more mature Admin Portal. SSOJet is the pricing-transparency alternative. Not a B2C suite.
WorkOS
WorkOS is the strongest B2B-first CIAM in 2026 by deliberate scope choice: every product surface assumes the buyer is selling to enterprise IT, not to consumers. AuthKit's 1M MAU free tier makes it a credible Auth0 alternative for B2B SaaS that does not need adaptive risk or B2C consumer flows. In 2026 the company is also documenting MCP step-up patterns for agents; that is still a tutorial surface, not a packaged agent-identity product like Auth0 for AI Agents. For pure B2B SSO, SCIM, and audit logs, WorkOS is hard to beat at any price point.
Where to next
FAQ
- Do I need SAML if I already have OIDC?
- Yes, for a long tail of enterprise IdPs that still only speak SAML. Offer both. Let the customer pick. Do not tell a bank to 'just use OIDC' in 2026.
- Should I build SAML or buy WorkOS?
- Buy if SSO is a sales checkbox and you are not an identity company. Build if federation is the product. The 60-day playbook is on this site; the engineering cost of metadata, signing-key rotation, and per-tenant ACS bugs is why WorkOS exists.
- Where does the tenant ID go?
- In the SP Entity ID or ACS path, consistently. Example: https://app.example.com/sso/acme/acs. Never infer tenant only from email domain; contractors will break it.
- Is IdP-initiated SSO safe?
- Treat it as optional and CSRF-sensitive. Prefer SP-initiated with RelayState bound to your session. If a customer requires IdP-initiated, whitelist their Entity ID and do not honor unsolicited assertions from anyone else.
Sources
- OASIS SAML 2.0
- CIAM Compass enterprise SSO guide
- WorkOS, Auth0 Organizations, and Frontegg public SSO docs