Enterprise deals block on SSO. You'll find out when it happens. An IT director at a 1,200-person company schedules a procurement call and the first question is: "Do you support SAML?" Your answer is "we're working on it" — and you lose the deal.
In B2B SaaS, "enterprise-ready" has a short definition: your product must accept that an IT team — not the end user — controls who can log in, what they can see, and when their access is removed. SSO is the protocol layer that makes this possible. SCIM is what makes it automatic. This post covers what it actually takes to implement both correctly, which tools absorb the hard parts in 2026, and which gotcha will burn you if you skip past it.
What Do Enterprise Customers Actually Require From Your Auth Layer?
Enterprise procurement teams require three things: federated authentication, automated provisioning, and clean offboarding. SAML (or OIDC) handles the first; SCIM handles the second and third. Every other enterprise auth feature — RBAC, audit logs, domain capture — is downstream of this triad.
The sequence matters. Customers ask for SSO before they ask for SCIM. Once a customer is on SSO and their headcount grows past 200 or 300, their IT team will tire of manually managing access and start asking about automated provisioning. You need both; just not at the same time.
SAML 2.0 is still the dominant enterprise SSO protocol in 2026, despite being over 20 years old. Every major identity provider — Okta, Microsoft Entra, Google Workspace, Ping, OneLogin — supports SAML as a first-class connection. OIDC is cleaner for modern architectures and the right choice for any new SaaS-to-SaaS integration. But you need SAML for the enterprise customer who has 400 existing SAML connections in Okta and is not migrating any of them.
Build both.
WorkOS, Auth0, and Stytch: Which One Actually Fits?
The right choice depends on whether you're selling to enterprise IT departments or to individual developers — and how fast you need to ship.
| Factor | WorkOS | Auth0 | Stytch | |---|---|---|---| | B2B-first design | Yes — organizations + SSO as core primitives | Partial — B2C roots, B2B bolted on | Yes — but acquired by Twilio in 2025 | | Base auth cost | Free up to 1M MAU (AuthKit) | Per-MAU, escalates with org size | Per-connection | | SSO / SCIM pricing | $125/connection/month, volume discounts above 15 | SSO locked behind enterprise tier ($1,500+/month) | $125/connection/month | | IT admin self-serve | Yes — hosted setup portal included | Requires custom build | Partial | | Roadmap stability | Low risk | Low risk (Okta ownership) | Elevated — Twilio acquisition uncertainty |
WorkOS is the fastest path to enterprise-ready for most B2B SaaS teams in 2026. AuthKit — WorkOS's authentication layer — is free up to 1 million monthly active users, covering email/password, social login, passkeys, and MFA. You pay nothing until an enterprise customer needs SSO or SCIM. Then you pay $125 per connected organization per month, dropping to $100 at 16 connections, $80 at 31, and $65 at 51. At 10 enterprise customers: $1,250/month. At 50: $6,250 before discounts.
Auth0 fits if your product genuinely spans consumer and enterprise audiences and you need deep customization. It's the most flexible option by a large margin. The cost: configuration complexity. Getting Auth0 production-ready for multi-tenant SSO takes 2-3x the engineering time of WorkOS on average, and per-MAU pricing creates unpredictable cost spikes when a large enterprise org signs on.
One note on Stytch: Twilio acquired them in 2025. The product is currently solid and pricing is competitive at parity with WorkOS, but if you're building something you plan to maintain for five years, weight the organizational risk of a small B2B-focused product inside a large telecom.
The multi-tenant architecture maps directly here: each enterprise customer is one organization record, and each organization gets its own SSO connection.
The SAML Attribute Mapping Trap
The single most common production SSO failure is attribute mapping inconsistency between identity providers. Here is what that looks like in practice.
Your SAML handler expects email as the user identifier. Okta sends it as NameID with format EmailAddress. Entra sends it as a separate SAML attribute following the full WS-Federation URI convention. Google Workspace sends emailAddress in different casing. Your handler extracts email from one source correctly and from another not at all, and the error surface is a generic "access denied" that gives users and IT admins nothing to debug.
Actually — the NameID format problem is worse than just naming. WorkOS's SAML attribute mapping guide documents this directly: Okta defaults to EmailAddress NameID format when you create a new SAML application. That works fine — until a user changes their email. Their NameID changes, your lookup fails, and a new account is created. They're now locked out of their original account's data. Use Persistent NameID format instead: a stable UUID-like identifier that doesn't change if the email does. Include this in your SSO setup guide for every customer's IT admin.
Per-IdP attribute naming is a separate issue. Okta calls the user's first name user.firstName. Entra inherits Microsoft's WS-Federation convention and sends a full URI namespace for the same claim. Both are valid implementations of a loose spec, and neither is changing. The fix is a per-IdP attribute mapping configuration layer: when a new customer connects their IdP, your system records which attribute name their provider uses for each field you care about. A managed service like WorkOS handles this automatically. Building it yourself: plan a week of integration testing against each IdP you need to support.
Two more sharp edges. RelayState: you'll be tempted to encode a post-login redirect URL directly into this parameter. Most IdPs enforce a size limit between 80 and 1,024 bytes and silently truncate or reject longer values. Use an opaque token and look up the destination server-side. Group claim bloat: Microsoft Entra sends group memberships in the SAML assertion by default. If a user belongs to more than 150 groups (SAML) or 200 (JWT), claims are silently dropped. Switch to "Groups assigned to the application" scoping, or use app roles instead.
SCIM or Just-in-Time Provisioning?
Ship JIT first. Add SCIM when an enterprise customer explicitly requires it. Almost always the right sequence.
JIT (just-in-time) provisioning creates a user account on first SSO login, with zero engineering overhead beyond your existing SSO handler. Your first 10 to 20 enterprise customers probably won't ask about anything more.
The problem: JIT cannot deprovision. When an employee is terminated and removed from Okta, JIT does nothing. The account persists. Sessions persist. Data access persists. A 2023 DoControl survey found that 31% of companies had former employees access SaaS assets after departure — exactly this failure mode. Enterprise security teams treat that number as a non-negotiable: SCIM is required for any contract where offboarding is auditable.
SCIM pushes both directions. User creation, attribute updates, group assignments, and deprovisioning. When IT removes an employee, SCIM sends an active: false patch to your endpoint within minutes on Okta, or within roughly 40 minutes on Entra — which batches sync events on its own schedule.
Gotchas when building SCIM yourself:
- Microsoft Entra sends non-RFC-compliant PATCH payloads by default. Append
aadOptscim062020to your SCIM Tenant URL to enable RFC 7644-compliant behavior. As of early 2026, still opt-in. - Okta omits
pathin PATCH operations; Entra includes it. Your handler needs to cover both. - Google Workspace provisions users, not groups. Automatic group-to-role mapping via SCIM isn't available for Google customers. Use JIT with assertion-based role claims instead.
- Initial sync is a load event. A customer with 3,000 users triggers thousands of concurrent requests on first connect. Rate-limit your endpoint and load-test before go-live.
For teams building on Next.js with Supabase auth, the SCIM endpoint is a separate Route Handler talking directly to your users table — isolated from the application's normal request path.
The in-house build estimate: 4-8 weeks for a single-IdP MVP; several months for a hardened multi-IdP implementation. WorkOS Directory Sync at $125/connection/month is often the correct trade-off.
Domain Capture in 60 Seconds
Domain capture routes a user to their organization's SSO connection by email domain alone. alice@corp.com types her email; your system looks up corp.com, finds the connected Okta tenant, and redirects her. No password field. Implement it as a domains table mapping verified domains to organization IDs. DNS verification (a TXT record challenge) is the gotcha: registrar propagation can take minutes to 48 hours. If you build it yourself, budget a week for edge cases. WorkOS handles this automatically.
What to Ship First
This is a procedure. Here is the right order.
- Email/password + email verification. Day one. Covers self-serve users, unblocks early sales, requires nothing from a customer's IT team.
- Social login (Google, GitHub). Before your first 50 customers. Most founders sign up with Google and expect it to work.
- SAML SSO. Before your first enterprise pilot. Two to three days with WorkOS; three to four weeks if you're writing XML parsers yourself.
- JIT provisioning. Enable alongside SSO. One config flag in most providers — eliminates the empty-account problem on first login.
- Domain capture. Add with SSO. Makes the IT admin setup flow self-contained.
- SCIM. Add when your first 1,000-seat customer requests it, or when SOC 2 Type I prep begins. Not before.
The SaaS MVP stack question is always about sequence. For auth, this is the sequence.
On Callidus — a multi-tenant SaaS for UK aesthetic clinics built on React and Firebase — I chose Firebase Auth with JWT-scoped role claims across six roles, not a SAML layer. The decision was deliberate: the target customer is an independent clinic owner, not a 500-person organization with a corporate Okta instance. Firebase Auth with email/password and role claims covered every real authentication scenario that came up during the build.
Know your customer before you plan your auth layer. The signal that you need enterprise SSO is when a prospect's IT director joins the evaluation call. That's when the clock starts.