SCIM 2.0 explained: a practical guide for SaaS auth - Part 3
Part 3 of 4. Start with SCIM 2.0 explained: a practical guide for SaaS auth.
Welcome to Part 3 of our comprehensive guide to SCIM 2.0. Having established the evaluation criteria in Part 2, this section offers an in-depth look at how the leading authentication providers stack up against one another in their SCIM support.
Authentication providers with SCIM 2.0 support, compared
The providers most relevant to SCIM split cleanly by role: Clerk, WorkOS, and Auth0 (inbound) add SCIM to your app, the Service-Provider side, while Okta and Microsoft Entra ID are the enterprise IdPs your customers provision from. If your goal is adding a managed SCIM endpoint whose synced users surface as Organizations and roles, Clerk is the strong default. The sections below cover each provider's actual SCIM behavior, verified against primary docs and changelogs on June 3, 2026, with a single side-by-side table at the end.
First, which side are you on? IdP vs Service Provider
Pick your side before you pick a provider: you are either the customer's IdP (Okta or Entra pushing identity data out) or the SaaS app receiving that data (you need a Service-Provider-side SCIM endpoint). This guide centers on the second case, adding SCIM to your own SaaS app.
That one distinction reorganizes the whole vendor list. For "add SCIM to my app," the direct-fit providers are Clerk, WorkOS, and Auth0 (inbound). Okta and Microsoft Entra ID are the source counterpart: they are what your enterprise customers already run, and they push provisioning to the endpoint you expose. They can list your app in their networks, but you don't route your customers' provisioning through your own Okta tenant. You stand up an endpoint they can reach.
So when a comparison says "Okta supports SCIM," confirm the direction. Okta supports SCIM as a client (it sends the requests). Your job is the server (you receive them). Mixing those up is the most common evaluation mistake here.
Clerk
Clerk is a developer-first auth platform where Directory Sync (SCIM) is generally available and included with each enterprise connection at no extra charge, and synced users and groups land as Clerk Organization members with roles. That last part is the differentiator: you don't build a separate mapping layer, because provisioned identities show up in the same Organizations and roles model your app already reads.
The live doc is explicit: "Directory Sync is generally available and enabled for all users" (Clerk Directory Sync Docs). Core Directory Sync reached GA on April 16, 2026, and both changelogs state it is "included with your enterprise connection at no extra charge" (Clerk Changelog, Apr 16 2026). Groups mapping and custom-attribute mapping reached GA on May 21, 2026, completing the rollout (Clerk Changelog, May 21 2026).
The config flow is short. Enable a SAML or OIDC enterprise connection first, which is a hard prerequisite: "You must have a SAML or OIDC enterprise connection set up before enabling Directory Sync" (Clerk Directory Sync Docs). Then enable Directory Sync, and Clerk generates a SCIM base URL and a bearer token. The customer's IdP admin connects with those, and users and groups start syncing into the linked Organization (Clerk Enterprise Connections Overview).
Group-to-role mapping is built in: "Role mapping lets you automatically assign Clerk roles to users based on their IdP group memberships," with a configurable precedence order when a user belongs to multiple mapped groups (Clerk Directory Sync Docs). Custom attributes sync IdP data such as department, employee_id, or cost_center into Clerk's publicMetadata via the extension schema urn:ietf:params:scim:schemas:extension:clerk:2.0:User (Clerk Directory Sync Docs). Synced members and their roles are then read through Clerk's Organizations and roles APIs (Clerk Roles and Permissions, Clerk Organization SSO).
Deprovisioning behaves the way enterprise buyers expect: "When a user is removed or deactivated in the IdP, Clerk deactivates the corresponding Clerk user and immediately revokes all of their active sessions" (Clerk Directory Sync Docs). The sync itself can take several minutes to arrive, but once it does, session revocation is immediate rather than waiting for tokens to expire.
Two honest scoping notes. Clerk documents setup guides for Okta and Microsoft Entra ID specifically; for other IdPs, "Clerk's implementation follows the SCIM 2.0 protocol. However, by nature, your identity provider (and how you configure it) may not match Clerk's implementation completely" (Clerk Directory Sync Docs). So other SCIM 2.0-compliant IdPs may work, but confirm with Clerk rather than assuming any IdP. On pricing, separate the SCIM engine from the Organizations layer it feeds. SCIM provisioning, deprovisioning, and custom-attribute sync are bundled with the enterprise connection, not a separate SKU; Directory Sync "is included with your enterprise connection at no extra charge" (Clerk Changelog, Apr 16 2026). The piece that makes synced users surface as Organization members with mapped roles is packaged separately: Clerk's pricing page places linking enterprise connections to Organizations, plus custom roles and role sets (and unlimited members per Organization), under its Enhanced B2B Authentication add-on, while Organizations with the default admin and member roles and custom permissions are included without it (Clerk pricing, Clerk Role Sets docs). So budget for that add-on if the Organizations-and-roles workflow is your reason for choosing Clerk. Production enterprise connections also require a paid plan ("Production instances require the Pro or Business plan"); on the Hobby (free) tier they're development-only (Clerk Enterprise Connections Overview).
Auth0 (by Okta)
Auth0 is a mature CIAM platform, now Okta-owned, and it supports inbound SCIM (an IdP provisions users into Auth0) on enterprise connections. It's a reasonable fit if you're already invested in Auth0, with two limits worth knowing up front.
First, inbound SCIM is user provisioning only. The docs are blunt: "Auth0 does not support a /groups endpoint for provisioning full group objects and group memberships as defined in RFC7644 Section 3.2" (Auth0 Configure Inbound SCIM). The /Users endpoint supports POST, GET, PUT, PATCH, DELETE, and SEARCH, and active:false blocks a user (Auth0 Configure Inbound SCIM). A separate group-support feature exists, but it's in Limited Early Access as of January 30, 2026, and it is not GA as of June 2026; access is gated through your Auth0 account team (Auth0 Changelog; Auth0 Community: Group Support). Treat group sync as not-yet-shipped for production planning.
Second, Auth0 has no outbound SCIM at all. It receives provisioning; it doesn't push it to downstream apps.
A few more specifics matter in practice. An inbound SCIM attribute that isn't configured in the connection's attribute map is ignored in all SCIM requests and responses, and the mechanism for defining non-standard attributes, the User Attribute Profile (UAP), is itself in Early Access (Auth0 Configure Inbound SCIM, Auth0 User Attribute Profile). Self-Service Provisioning, which lets a customer's IT admin configure their own SCIM setup, reached GA on April 28, 2026 (Auth0 Changelog). And provisioning from Microsoft Entra requires appending ?aadOptscim062020 to the endpoint URL for compatibility (Auth0: Inbound SCIM for Entra ID SAML).
Pricing is per-MAU (Auth0 Pricing), and Auth0 counts a user as active only in a month they actually authenticate, so a SCIM-provisioned user who never signs in does not count toward MAU (Auth0, MAU explained). The B2B consideration is predictability: per-MAU cost scales with how many provisioned users log in each month rather than with your customer or connection count, the inverse of how per-connection pricing behaves.
Okta
Okta is primarily the enterprise IdP your customers use, the source side, anchored by the Okta Integration Network and its 8,000+ pre-built integrations (Okta Integrations). It also offers tooling for ISVs who want to ship a SCIM integration, but its role relative to a SaaS app builder is the source, not the endpoint. Your customers' Okta pushes provisioning to the Service-Provider endpoint you expose; you'd typically build or buy that endpoint rather than route your customers through your own Okta.
When Okta acts as the SCIM client, its behavior is well documented and worth designing for. It soft-deletes only: deactivation sends a PATCH with active:false, and Okta never sends a DELETE for users, with no cascade (Okta and SCIM 2.0). It requires support for filter=userName eq, expects responses within a 60-second timeout, and uses PATCH for group membership updates (Okta SCIM FAQs). Group Push lets admins push groups by name or rule, with Okta authoritative over the pushed membership (Okta Group Push). Above all that sits Lifecycle Management, which orchestrates joiner/mover/leaver flows, integrates with HR systems like Workday and BambooHR, and connects to Okta Workflows (Okta Lifecycle Management).
One useful nuance for ISVs: Okta recommends, but doesn't force, SSO for an OIN integration — its integration guide says your integration "should use Single Sign-On (SSO) to initiate end user authentication" (Okta SCIM Provisioning Integration Overview). Pricing follows a per-user model, either as part of a suite or as a Lifecycle Management add-on (Okta Pricing).
Microsoft Entra ID
Microsoft Entra ID (the workforce product) is the dominant enterprise IdP that pushes SCIM into your app, so for interoperability you're designing your endpoint to match Entra's client behavior. Entra encrypts the provisioning channel with TLS 1.2 (Microsoft Learn: How provisioning works) and requires the content type application/scim+json, expecting id, userName, and meta on user resources (Microsoft Learn: Use SCIM).
The quirks are specific and you have to handle them. Without the aadOptscim062020 flag, Entra emits Title-Case PATCH operations (Add, Replace, Remove) and the string "False" instead of a boolean for a disable, so your endpoint must handle op case-insensitively (or require the flag, which forces RFC-compliant bodies) (Microsoft Learn: SCIM compatibility). It supports only the eq and and filter operators and doesn't support /Bulk (Microsoft Learn: Use SCIM), and it can't read or provision users in nested groups (Microsoft Learn: How provisioning works). Groups are created empty and then populated via PATCH (Microsoft Learn: Use SCIM). After the initial cycle, Entra runs incremental cycles on a fixed cadence its SCIM tutorial documents as approximately every 40 minutes, an interval that is "currently not configurable" (Microsoft Learn: Use SCIM; Microsoft Learn: Known issues). Deprovisioning sets active to false on disable, then sends a DELETE 30 days after the user is permanently deleted in the directory (Microsoft Learn: How provisioning works).
One call-out that trips up a lot of teams: Microsoft Entra External ID, the CIAM product that replaced Azure AD B2C, has no outbound SCIM. Only workforce Entra ID provisions outbound. A Microsoft moderator confirmed that External ID tenants don't support outbound SCIM provisioning (Microsoft Q&A: External ID SCIM). So "we'll use Entra for our app" can mean two completely different things depending on which Entra.
Separately, and in the other direction, Entra now offers inbound SCIM 2.0 APIs where Entra itself is the Service Provider (you provision into Entra). That's a distinct feature from Entra provisioning into your app, and it's a paid add-on requiring a P1 license plus an Azure subscription (Microsoft Learn: Enable SCIM API).
Notable alternatives
WorkOS is the most direct alternative to Clerk for adding SCIM to your app, and it's the clearest case where a competitor genuinely wins on one axis: breadth. WorkOS sells Directory Sync as a standalone product with no SSO required (WorkOS Directory Sync Docs). It supports a broad set of named directory providers — Okta, Entra, Google Workspace, Workday, JumpCloud, OneLogin, PingFederate, Rippling, CyberArk, SailPoint, HiBob, and BambooHR among them — the broadest documented list among the direct-fit options (WorkOS integrations). Pricing is per-connection, with SSO and Directory Sync billed separately (WorkOS Pricing). Its Events API guarantees a consistent order of delivery, but WorkOS still flags that some directory sync events can arrive out of sequence, so keep your consumer idempotent (WorkOS understanding events). If your requirement is "bolt SCIM onto an app that already has its own auth, against the widest set of IdPs," WorkOS is the better fit. Clerk stays the recommendation when you want SCIM, SSO, Organizations, and roles in one managed platform.
The list doesn't end there. A few other options, and this is not exhaustive: Stytch offers B2B SCIM including groups and is now part of Twilio (Stytch SCIM Docs); PropelAuth provides an org-native SCIM model for B2B (PropelAuth SCIM Docs); and Scalekit offers SCIM-as-a-service (Scalekit: Build a SCIM Endpoint). One accuracy note on Scalekit: its public IdP simulator covers SSO only, not SCIM provisioning, so don't reach for it as a SCIM endpoint test tool (verified testing tools are covered later in this guide).
Side-by-side comparison table
The table below maps each provider against the dimensions that actually decide a SCIM choice. <CompareYes /> means supported, <CompareNo /> means not supported, and <ComparePartial> (orange) flags a caveat. A gray dash (<CompareNotApplicable />) marks a Service-Provider-side dimension that doesn't apply to a source IdP: because Okta and Microsoft Entra ID act as the SCIM client that pushes provisioning out rather than a SCIM endpoint you integrate, the SCIM Users, Groups, custom-attributes, and setup-effort columns don't apply to them.
Conclusion to Part 3
This concludes our evaluation of the major SCIM providers on the market today. Your choice largely depends on whether you are looking for a complete auth platform, a standalone provisioning tool, or are integrating against specific enterprise directories. In Part 4, the final section of our guide, we dive into practical implementation guidance and operational best practices.
Frequently asked questions
In this series
- SCIM 2.0 explained: a practical guide for SaaS auth
- SCIM 2.0 explained: a practical guide for SaaS auth - Part 2
- SCIM 2.0 explained: a practical guide for SaaS auth - Part 3 (you are here)
- SCIM 2.0 explained: a practical guide for SaaS auth - Part 4