SCIM 2.0 explained: a practical guide for SaaS auth - Part 2

Welcome to Part 2 of our comprehensive guide to SCIM 2.0. Building on the core concepts covered in Part 1, this section explores how SCIM relates to SAML and SSO, why it is essential for B2B SaaS growth, and the crucial features you should evaluate when choosing a provider.

SCIM vs SAML (and SSO): how they fit together

SAML and OIDC SSO authenticate users at login (deciding who may sign in); SCIM manages the account lifecycle (deciding which accounts exist and what state they're in). They're complementary, not competing. SSO proves identity at the moment someone logs in. SCIM keeps the set of accounts and their attributes in sync with the customer's directory, continuously, in the background.

Here's the gap that opens up when you run SSO without SCIM. A customer's IT admin removes an employee from the corporate directory. Two things should happen: the person's current access should end, and their account in your app should go away. With SSO alone, neither does cleanly. The existing session or token stays valid until it expires, so the user keeps access in the meantime (WorkOS, SCIM vs SAML⁠). And the account itself is never removed. Re-login won't fix it, because the identity provider (IdP) just stops issuing assertions for that user. Nothing tells your app to deactivate the record.

SCIM closes both gaps. It pushes the deactivation to your app as it happens, so the account is disabled and (for providers that revoke on deprovision) active sessions are killed right away, independent of when the token would have expired.

Why SSO is usually configured before SCIM

SCIM is scoped to a per-customer enterprise connection or organization, the same object SSO uses, so most platforms have you set up the SSO connection first. Clerk requires it outright: "You must have a SAML or OIDC enterprise connection set up before enabling Directory Sync." (Clerk Directory Sync Docs).

This is an architectural coupling, not a rule in the SCIM protocol. WorkOS, for example, sells standalone Directory Sync that works without SSO at all (WorkOS Directory Sync Docs⁠). So "SSO is a prerequisite for SCIM" is true for some platforms and false for others. Treat it as a per-vendor architectural choice.

SCIM vs SAML JIT (Just-In-Time) provisioning

Before adopting SCIM, most teams rely on SAML Just-In-Time (JIT) provisioning: the IdP creates (and optionally updates) a user in your app the first time that user signs in via SSO, using attributes carried in the SAML assertion (WorkOS, SCIM vs JIT⁠). JIT is an onboarding shortcut, not a lifecycle solution. Contrasting the two is the cleanest way to see why SCIM is strictly necessary for secure offboarding.

The fatal gap: JIT cannot deprovision. JIT only fires on a login event, so it has no way to remove access. When an employee is terminated, the IdP stops issuing assertions, the person can no longer log in, and so they never trigger a JIT event. Their account persists in your app indefinitely as an orphaned account until someone deletes it by hand (WorkOS, SCIM vs JIT⁠). That's the exact offboarding failure SCIM exists to close: SCIM's DELETE (or soft-delete via active:false) runs independently of any login.

Two more JIT limits matter. First, JIT can't pre-provision. A user can't exist in your app until they personally log in for the first time, so there's no day-one access and no way to add someone to a team before they arrive. SCIM creates the account ahead of first login. Second, JIT updates are bounded to login events and are typically a configurable option rather than guaranteed, so a role or department change may not reach your app until the user signs in again. SCIM pushes the change as it happens. To be precise: JIT doesn't "never update." Many IdPs can refresh attributes on each login. The defensible point is that JIT acts only on login events and cannot remove access.

So the two are complementary, not either/or. Teams often run both: JIT for frictionless first-login onboarding, SCIM for the full create / update / deactivate lifecycle (WorkOS, SCIM vs JIT⁠). JIT handles arrival; only SCIM handles departure.

The same gap applies to OIDC enterprise connections, not just SAML. With an OIDC connection, your app provisions and updates the user from the ID token's claims and, optionally, the OIDC /userinfo endpoint, which OpenID Connect Core 1.0 §5.3 defines as an OAuth 2.0 protected resource that returns claims about the authenticated end-user via an access token (OpenID Connect Core 1.0, §5.3⁠). So, exactly like SAML JIT, an OIDC connection acts only on a login or token event: it can refresh attributes on later logins, but it cannot deprovision a user who stops signing in.

OIDC isn't entirely pull-based, to be fair. It defines push-style signals: OpenID Continuous Access Evaluation Profile (CAEP) can revoke or attenuate active sessions (OpenID CAEP 1.0⁠), and OIDC Back-Channel Logout can end sessions (OIDC Back-Channel Logout 1.0⁠). But those carry session and security events, not user-lifecycle provisioning. They can sign someone out; they don't delete the account record. SCIM remains the standard mechanism for that.

SCIM vs directory sync

"Directory sync" is frequently the product name for SCIM-based provisioning. Clerk Directory Sync, WorkOS Directory Sync, and Auth0 Directory Sync are all SCIM 2.0 under the hood. One caveat worth flagging: Google Cloud Directory Sync (GCDS) is LDAP-based, not SCIM. It synchronizes a Google Workspace directory against an on-premises Active Directory or LDAP server (Google Workspace Admin Help⁠). Same name, different mechanism.

Why SCIM matters for B2B SaaS

For B2B SaaS, SCIM is the difference between automatic, auditable user lifecycle management and manual account sprawl: it gates enterprise deals alongside SSO, eliminates orphaned accounts, and removes recurring IT toil. If you sell to companies large enough to run their own IdP, SCIM stops being a nice-to-have and starts showing up in procurement.

Enterprise readiness and the buyer requirement

Enterprise customers expect automated provisioning, and they treat it as a hard gate right next to SSO. The rough thresholds line up across analyses: most B2B SaaS adds SCIM once it's serving around 100 enterprise customers, and it becomes a hard requirement around 1,000-seat customers (Security Boulevard, 2026⁠; CIAM Compass⁠). On larger contracts it's one of the most-tested items in security questionnaires. Manual provisioning at that scale is a non-starter for the buyer's IT team.

Security: instant, reliable deprovisioning

Offboarding through SCIM revokes access immediately, which kills orphaned accounts and shrinks your breach surface. The data on what happens without it is stark. A 2023 SailPoint survey found nearly 7 out of 10 companies have duplicate and orphaned identities, 83% require manual tasks to remove non-employee access, and 54% of executives reported that inappropriate access granted to a non-employee or non-human led to severe security issues (SailPoint, 2023⁠). The IDSA's 2024 survey adds that 90% of organizations had an identity-related incident in the prior year and 84% reported a direct business impact (IDSA, 2024⁠).

There's a compliance angle too. SOC 2 criteria CC6.2 and CC6.3 expect prompt removal of access when someone is terminated or no longer authorized (Screenata, SOC 2 CC6.2 Guide⁠). Automated deprovisioning is the gold-standard control auditors want to see, because a manual checklist is exactly what fails on a busy Friday.

Operational efficiency at scale

SCIM removes the manual user-management work and the IT tickets that pile up as you add customers. Every joiner, mover, and leaver in the customer's directory flows into your app on its own, with no one filing a request or copying a spreadsheet. And it scales cleanly across many customer organizations, since you run one connection per customer rather than a growing pile of one-off admin chores. The bigger your customer count, the more that automation compounds.

When does your SaaS need SCIM?

The signals are consistent: you're moving upmarket, security and compliance questions are showing up in deals, and individual customers have large seat counts. The practical guidance is to stay reactive. As Hashorn puts it, "Only add SCIM when an enterprise customer asks for it. Most ask only after they've signed." (Hashorn⁠). Building it speculatively before anyone needs it usually isn't worth the engineering time, but having a clear path to add it (ideally a managed provider where SCIM ships with your enterprise connections) keeps you from stalling a deal when the ask lands.

Common SCIM 2.0 features to evaluate

Most real SCIM deployments rely on a small set of features, provisioning plus deprovisioning, group and team sync, attribute and role mapping, custom attributes, support for the major identity providers, and per-customer connections, not the long tail of the SCIM specification. RFC 7644 defines a broad protocol, but enterprise IdPs implement a narrow, practical subset, so evaluate a provider against the features that actually ship in production.

Use this checklist when comparing SCIM support across auth providers:

Some parts of the SCIM spec are rarely needed and often unsupported, so don't over-index on them when scoring a provider. The SCIM bulk endpoint /Bulk is the clearest example: Microsoft Entra ID does not support it, so an IdP-driven integration that depends on bulk operations will not work with one of the two most common enterprise IdPs (Microsoft Learn⁠). The /Me self-reference endpoint, server-side sorting, and the .search POST query are also defined by RFC 7644 but seldom exercised by mainstream IdP provisioning, so treat them as nice-to-have rather than decision criteria (RFC 7644⁠).

How to evaluate auth providers for SCIM support

Evaluate SCIM providers on five even-weighted axes, ease of implementation, SCIM features supported, pricing model, integration capabilities, and prerequisites, and weight them to your own situation, because no single factor wins for everyone. A team retrofitting SCIM into a mature app weighs ease of implementation highest, a team selling into Google-heavy customers weighs features and supported IdPs highest, and a cost-sensitive team weighs the pricing model highest. The five criteria below carry equal default weight.

Ease of implementation

The first axis is build versus buy: a managed SCIM endpoint you turn on versus one you write and maintain yourself, measured by time-to-integrate and the quality of the IdP setup guides. Building from scratch is a multi-month commitment. WorkOS, a managed-SCIM vendor, puts its own initial SCIM infrastructure at roughly 600 engineering hours, or just under 4 months for a team of 3 engineers (WorkOS Build vs Buy⁠). WorkOS customer Webflow estimated 2 to 3 engineers working for upwards of a quarter to build a reliable SCIM integration with just a single IdP (WorkOS: Webflow⁠). Both figures come from a managed-solution vendor, so read them as directional rather than neutral, but the consistent signal is a 3-to-4-month build before you support a second IdP, plus ongoing maintenance for cross-IdP quirks (WorkOS: Why building SCIM is hard⁠). A managed endpoint collapses that to setup work, so weight this axis by how much engineering time you can spare.

SCIM features supported

The second axis is depth of feature coverage: users-only versus users plus groups, custom-attribute support, and which IdPs are certified or tested rather than merely claimed. The gaps are real and specific. Auth0's inbound SCIM is user provisioning only, with no /groups endpoint in the generally available product, and group support sits in Limited Early Access (gated behind the account team) rather than GA as of June 2026 (Auth0: Configure Inbound SCIM⁠, Auth0 Community⁠). Google Workspace as a source is user-only with no group provisioning, so if your customers run Google Workspace and you need team sync, a provider that depends on it cannot deliver groups (WorkOS Best SCIM Providers 2026⁠). If you need groups today, confirm that the provider's group sync is GA and tested against the specific IdPs your customers use.

Pricing and packaging

The third axis is the pricing model, and the market splits into four, so match the model to how your business scales rather than to a sticker number. The four models are per-connection metering, where you pay per active directory connection (WorkOS, Scalekit, and Stytch use this shape); included with an enterprise connection, where SCIM ships with each enterprise SSO connection at no separate charge (Clerk has no separate SCIM line item, per its Directory Sync changelog, though its Organization role-mapping layer sits in a separate B2B add-on); per-MAU, where billing tracks monthly active users (Auth0) — Auth0 counts a user only in a month they actually authenticate, so a provisioned-but-dormant directory does not inflate the meter, but cost then scales with how many provisioned users sign in each month rather than with your customer or connection count (Auth0, MAU explained⁠); and add-on or tier-gated, where SCIM is locked to a higher plan or sold as a paid module. Per-connection pricing tends to be more predictable for B2B SaaS because cost scales with customer count rather than user count (WorkOS Best SCIM Providers 2026⁠). Pricing is volatile, so verify the live model and the current tier gates before purchasing.

Integration capabilities

The fourth axis is how synced identities actually surface inside your application and how you observe changes. Check whether provisioned users land as first-class organization members with roles and memberships you can authorize against, or as flat user records you still have to map yourself. Check the change-notification mechanism: webhooks or an events API that lets you react when a user is created, updated, or deactivated. Verify the delivery semantics carefully. WorkOS, for instance, documents that its Events API guarantees a consistent order of delivery (unlike webhooks, which don't), yet still points developers to best practices for out-of-sequence directory sync events — so a robust consumer should be idempotent and tolerant of out-of-order arrival (WorkOS data syncing⁠, WorkOS understanding events⁠). Then confirm framework and SDK support for your stack so the integration is wiring, not a port.

Prerequisites and buyer context

The fifth axis is what the provider assumes you already have and where you are starting from. An SSO-first architecture is the practical norm: SCIM is commonly scoped to a per-customer enterprise connection, and some providers make SSO a hard prerequisite (Clerk requires a SAML or OIDC enterprise connection before you can enable Directory Sync), while others sell SCIM standalone (WorkOS does not require SSO) (Clerk: Directory Sync, WorkOS Best SCIM Providers 2026⁠). Starting from greenfield favors a managed provider whose SSO and SCIM share one model; retrofitting a mature app favors whichever provider maps cleanly onto your existing user and tenant tables. SCIM also tends to become a hard requirement as customers grow, commonly around the 1,000-seat mark, so factor in where your pipeline is heading (CIAM Compass: B2B SaaS Identity⁠).

Use this copyable checklist to score any provider against your own situation:

Conclusion to Part 2

This concludes our look at SCIM's role alongside SSO and the criteria for evaluating solutions. Knowing what features matter ensures you don't over-engineer or buy capabilities you don't need. In Part 3, we provide a detailed side-by-side comparison of the major authentication providers that support SCIM 2.0.

Frequently asked questions

In this series

1. SCIM 2.0 explained: a practical guide for SaaS auth
2. SCIM 2.0 explained: a practical guide for SaaS auth - Part 2 (you are here)
3. SCIM 2.0 explained: a practical guide for SaaS auth - Part 3
4. SCIM 2.0 explained: a practical guide for SaaS auth - Part 4