Single Sign-On for B2B SaaS in 2026: SAML and SCIM Done Right

Consider a two-person SaaS team whose first enterprise prospect asks on a procurement call: "Do you support SAML?" If the honest answer is "not yet", your first action is a question back: which identity provider do you use, and do you need automatic user provisioning or only login? That answer decides whether you need SSO, SCIM, or both, and how much of it you should build yourself.

In B2B SaaS, "enterprise-ready" comes down to one idea: a customer's IT team, not the end user, controls who can sign in and when access ends. SSO is the protocol that hands over login. SCIM is the protocol that hands over the account lifecycle. This post covers what each requires, what the main vendors charge as of September 2026, and the gotchas that break integrations in production.

What Do Enterprise Customers Actually Require From Your Auth Layer?

Enterprise buyers typically ask for three things: federated login through their identity provider, automatic provisioning of accounts, and fast removal of access when someone leaves. SAML or OIDC covers the first, SCIM covers the other two.

Customers usually ask for SSO before SCIM. Once a customer's headcount grows, manual user management becomes a chore for their IT team and the provisioning question follows. You need both eventually, but rarely in the same quarter.

SAML 2.0 is still the protocol most enterprise identity providers expect. It was approved as an OASIS Standard on 1 March 2005, so it is over 20 years old. OIDC is the cleaner choice for new integrations, but a customer who already runs their apps through SAML will ask for SAML. Plan to support both, and store the protocol as a property of each connection rather than a global switch, so one organization can use SAML while another uses OIDC.

The reason this matters beyond sales is offboarding. DoControl's State of SaaS Data Security 2024 report states that 9 out of 10 companies have former employees who accessed assets stored in SaaS applications after they left (DoControl's 2023 analysis of companies with over 1,000 employees). Security teams know this number, which is why auditable offboarding shows up in enterprise contracts.

WorkOS, Auth0 or Stytch: Which Costs What for Enterprise SSO?

WorkOS charges per SSO connection from the first one, Auth0 bundles a few connections into its B2B plans, and Stytch includes five on its free plan, according to each vendor's pricing page on 30 September 2026.

WorkOS lists the same tiers for SSO and Directory Sync: $125 per connection for 1 to 15, $100 for 16 to 30, $80 for 31 to 50, $65 for 51 to 100, and custom pricing above 100. A "connection" is one group of end users authenticating through an identity provider, so one enterprise customer is normally one connection. Ten SSO connections cost $1,250 a month at list price. SCIM would be priced on top.

Auth0 is the more flexible option if your product serves both consumers and enterprises and you need deep control over login flows. The cost of that flexibility is configuration work, which I expect to be higher than with a B2B-first vendor, though I have no measured comparison to cite.

On Stytch, the acquisition matters for planning, not for today. Twilio announced it on 30 October 2025, and Stytch's own announcement says there are no immediate changes to contracts, pricing, SDKs or API keys. If you plan to depend on it for years, watch its changelog.

A multi-tenant architecture maps onto all three: one enterprise customer is one organization record with one SSO connection.

SAML vs SCIM Provisioning: Do You Need Both?

SAML handles login, SCIM handles the account lifecycle, and you can ship SAML with just-in-time provisioning first. Add SCIM when a customer needs automatic deprovisioning or their auditors ask for it.

Why Just-in-Time Provisioning Is Not Enough for Offboarding

JIT provisioning creates an account the first time someone signs in through SSO. It costs almost nothing beyond your SSO handler, which suits your first enterprise customers. Keep the session lifetime short for those accounts, because that is the only lever you have until SCIM exists. The limit is structural: nothing tells your app when an employee is removed from the identity provider. The account and any active session stay until you revoke them, which is the scenario the DoControl number above describes.

SCIM closes that gap. The identity provider pushes user creation, attribute changes, group membership and deactivation to your endpoint. RFC 7643 defines the active attribute on the User resource as a boolean administrative status, which is what a deactivation flips.

What Breaks When You Build SCIM Yourself

• Entra PATCH formatting. Microsoft's SCIM compatibility page says its PATCH behavior for disabling users and several other operations is RFC-compliant only when you add the aadOptscim062020 flag to the tenant URL, and the page, last updated in 2026, still describes it as a flag. Without it, Entra sends "op": "Replace" with "value": "False" as a string.
• Case of operation names. Microsoft documents that Entra emits Add, Replace and Remove, and tells implementers not to require a case-sensitive match. Normalize before you switch on it.
• Missing path. RFC 7644 says path is optional for add and replace operations and required for remove. A handler that assumes a path will fail on valid requests.
• Sync delay. Entra runs its sync about every 40 minutes, per the same Microsoft page, so a removal is not instant.
• First-sync load. This is my inference: the initial cycle provisions every assigned user, so rate-limit the endpoint and test it with a few thousand fake users before a large customer connects.

The SAML Attribute Mapping Trap

The most common SSO bug is that identity providers name the same field differently. WorkOS's attribute mapping guide gives an example: email arrives as user.email from Okta and as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress from Microsoft Entra ID, because Microsoft follows WS-Federation claim conventions.

The same guide describes two NameID formats. EmailAddress is the most common, while Persistent is an opaque, stable identifier that survives an email change. If you key users on an email-based NameID and someone's email changes, your lookup can miss and create a second account. Recommendation: key on a persistent identifier where the provider offers one, and store the IdP subject next to the email.

Keep an attribute mapping per connection that records which attribute each customer's provider uses for email, first name, last name and groups. A managed service hides this. If you build it, test against each provider you claim to support.

For groups, Entra limits what a token carries. Microsoft's optional claims documentation states the number of groups emitted is limited to 150 for SAML assertions and 200 for JWT, and recommends the "Groups assigned to the application" option for large organizations.

Also avoid putting a redirect URL directly in RelayState. Store the destination server-side and pass an opaque token, which keeps the value small and stops open-redirect abuse.

Domain Capture

Domain capture routes a user to their organization's SSO connection by email domain. You keep a table of verified domains per organization, and verification is usually a DNS TXT record challenge. DNS propagation delays are the UX trap, so build a pending state for domains that have not verified yet.

What Should You Ship First?

Ship email and password, then social login, then SAML with JIT and domain capture, and SCIM last. The order follows what a buyer blocks on, not what is technically interesting.

1. Email/password with email verification. It serves self-serve users and needs nothing from a customer's IT team.
2. Social login. Most founders sign up with Google and expect it to work.
3. SAML SSO, before your first enterprise pilot. Buying it from a vendor is faster than writing XML signature handling yourself.
4. JIT provisioning and domain capture, alongside SSO, so the IT admin's setup flow is self-contained.
5. SCIM, when a customer asks or when a compliance effort such as SOC 2 Type I starts to ask how access is removed.

Once SSO is live, the next layer is what a signed-in user may do, which is covered in RBAC design for SaaS. The SaaS MVP stack page shows where auth sits in the wider build order.

My Callidus case study (React, Firebase and Stripe Connect) documents tenant-scoped JWT claims that carry tenantId and role, with six roles. It does not include SAML or SCIM. This suggests, but does not prove, that small independent customers rarely need them. For a Next.js and Supabase build, the Supabase auth stack page covers the starting point.

Which identity provider does your next enterprise prospect use, and have you asked yet?