Best SCIM Provisioning Tools

SCIM arrives in your roadmap the same way every time. A security questionnaire from an enterprise prospect contains a line item about automated user provisioning and deprovisioning. Sales says it is a checkbox. Engineering estimates two weeks because the specification looks small. Six months later you are maintaining per-customer workarounds, and somebody has discovered that a departed employee at your largest account still had an active session for three weeks.

The gap between the estimate and the reality comes from one misunderstanding, which is worth clearing up before comparing anything. SCIM is a specification describing a REST API shape and a user schema. It is not a service, not a synchronisation engine, and not a guarantee that anything will be kept in sync. The specification tells an identity provider how to ask you to create, update and deactivate a user. Everything about whether those requests are correct, complete, timely or ever sent at all is implementation behaviour, and implementation behaviour varies considerably.

That is why the compliance requirement your customer actually has, which is “when we fire someone, their access to your product ends”, is not satisfied by the sentence “we support SCIM”. It is satisfied by a working integration against their specific identity provider, monitored so you find out when it stops.

Key takeaways

• SCIM standardises the API shape and a base user schema. It says nothing about sync frequency, retry behaviour, delete semantics, or what happens after a failure, so those vary by identity provider.
• Deprovisioning is the requirement buyers care about and the one that fails most quietly. A provisioning connector that stops firing looks exactly like a customer who has not hired anyone lately.
• Group and role sync is substantially harder than user sync, because group membership changes are where identity providers differ most and where ordering matters.
• Most teams meet SCIM after they have already shipped SSO, under deal pressure, with a user model that was not designed for externally managed lifecycle.

SCIM: the standard underneath, not a product

SCIM, the System for Cross-domain Identity Management, defines a REST API and a JSON schema for managing identities across systems. The identity provider is the client. Your application is the server. The provider pushes changes to you.

The core of it is small. A /Users endpoint and a /Groups endpoint supporting create, read, update, patch and delete. A defined core schema with attributes like userName, name, emails and active, plus an enterprise extension carrying things like department, manager and employee number. A filter syntax for querying. A PATCH operation format for partial updates. A /ServiceProviderConfig endpoint where you declare which optional parts you support.

What it gives you

• A single API contract, so one implementation on your side is theoretically reachable by any compliant identity provider rather than requiring a connector per customer
• A defined user schema, so active, userName and emails mean the same thing across providers and you are not mapping field names per integration
• An extension mechanism, so custom attributes have a defined place to live rather than being smuggled into unrelated fields
• A declaration endpoint, so a provider can discover whether you support filtering, patch, bulk operations and sorting instead of guessing
• Push semantics, so lifecycle changes can reach you promptly rather than waiting for a nightly export nobody watches

What it does not do

• Guarantee when anything happens. The specification says nothing about sync frequency, so a provider may push on change, on a schedule, or on a schedule that is longer than you assumed
• Define retry or failure behaviour. What a provider does when your endpoint returns an error, and how long it keeps trying before giving up permanently, is entirely up to that provider
• Standardise delete. Some providers send DELETE, some send a PATCH setting active to false, some do both, some do neither and simply stop referencing the user
• Tell you how to model accounts. Mapping an externally provisioned user onto your existing account, tenant and role model is your design problem, and the hardest part of the work
• Cover authentication. SCIM provisions accounts. Those accounts still sign in through SSO, which is a separate integration with separate failure modes
• Provide any monitoring. Nothing in the specification tells you that provisioning has stopped, which is exactly the failure you most need to detect

So when a vendor on this page says it supports SCIM, the useful follow-up questions are which providers it is actually certified or tested against, how it represents deactivation, and what it does when a request fails.

Where implementations diverge in the wild

The specification has optional parts and ambiguous corners, and the major identity providers have each resolved them differently. These are the divergences that generate per-customer work.

Delete versus deactivate. The single most consequential difference. One provider removes a user from an application assignment by sending DELETE /Users/{id}. Another sends PATCH with active: false. A third does nothing at all and relies on the SSO assertion simply failing thereafter. If your implementation treats DELETE as a hard delete, you will lose audit history and any records owned by that user. The safe implementation treats both as deactivation, keeps the record, and blocks authentication.

PATCH semantics. The patch operation format is the most inconsistently implemented part of the specification. Path expressions for multi-valued attributes, whether replace on an array means merge or overwrite, and how a provider addresses a specific email or group member all vary. An implementation that handles one provider’s patch shapes correctly will reject another’s.

Filtering. The filter grammar supports more than most servers implement and more than most providers use. In practice the common case is filtering users by userName, and support for anything beyond that is worth checking rather than assuming.

Pagination. Start index and count are specified, but default page sizes and provider behaviour at boundaries differ, and a mismatch shows up as users silently missing from a sync rather than as an error.

Attribute mapping. The base schema is small, so anything you actually need beyond email and name relies on the enterprise extension or on custom attributes the customer’s administrator configures by hand on their side. That configuration is per customer, done by someone at the customer, and is a frequent source of integrations that work for eleven customers and not the twelfth.

Bulk operations. Specified, rarely implemented, and rarely used. Do not design around them.

Error handling. How a provider interprets your status codes determines whether a transient failure is retried or treated as permanent. A 500 returned during a deploy may be retried for hours or may quietly mark the connector unhealthy, and you cannot tell from your side which happened.

The practical consequence: “SCIM compliant” is not a sufficient specification for your implementation. Certified against the specific identity providers your customers use, tested with their real configurations, is.

Deprovisioning is the whole point, and it fails silently

Every buyer asking for SCIM is asking for one guarantee: that when a person leaves, their access ends. Provisioning is the convenient half. Deprovisioning is the half with a compliance auditor attached.

It is also the half that breaks without telling anyone, because of an unfortunate symmetry. A connector that has stopped firing produces no requests. A customer with no staff changes also produces no requests. From your server’s perspective, these look identical. Nothing errors, no alert fires, and the integration is silently dead until somebody runs an access review.

Four ways it stops.

Credential expiry. The bearer token the provider uses to call your API expires or is rotated. Requests start failing with a 401, the provider marks the connector unhealthy on their side, and nobody at the customer is watching that screen.

A schema or endpoint change on your side. You deploy a change that alters a response shape or a validation rule. Requests now fail. Depending on the provider, it retries for a while and then stops.

Administrative changes at the customer. Somebody reorganises groups, removes the application assignment, or rebuilds the integration during an identity provider migration. Provisioning stops being configured and nobody tells you.

Silent partial failure. The worst version. Creates succeed and deactivations fail, or the other way round. The connector looks healthy because traffic is flowing, and only one direction of the lifecycle is actually working.

What to build, on your side, regardless of which tool you buy.

Alert on absence, not just on errors. For each customer with provisioning configured, track the time since the last successful request. A tenant that has been silent far longer than its own historical pattern is the signal. This is the only detection that catches a connector that stopped firing.

Log every SCIM request with its outcome, and keep it queryable. When a customer’s security team asks whether a specific person was deprovisioned and when, you need to answer with evidence rather than inference. That is an audit logging requirement as much as an identity one.

Terminate sessions on deactivation, do not just block login. A deactivated user with a live session keeps working until that session expires. If deprovisioning only sets a flag checked at login, your actual revocation time is one session lifetime, which may be days. The customer believes it is instant.

Expose provisioning status to the customer. Last sync time, last error, counts. The customer’s administrator is the only person who can fix a broken configuration on their side, and they will not know it is broken unless you show them.

Needs first-hand data: For each identity provider you support, run a timed deprovisioning test: deactivate a user in the provider and record the wall-clock delay until the SCIM request arrives, until your record is marked inactive, and until that user’s existing session actually stops working. The third number is the one your customer thinks they are buying, and it is usually much larger than the first.

Group sync is harder than user sync

Users are a flat list. Groups are a graph, and the specification handles them less cleanly.

Membership updates are patches to an array. Adding one person to a group of two thousand should be a patch adding one member, and some providers instead send the whole membership list. Handling both correctly is required, and the full-list case is expensive.

Ordering is not guaranteed. A membership change referencing a user who has not been created yet is common, especially during initial sync. Your implementation has to tolerate a reference to an unknown user rather than failing the request.

Nested groups are not really covered. Identity providers support group hierarchies. SCIM’s group model does not express them well, so providers typically flatten membership before sending. What arrives is the flattened result, meaning you cannot reconstruct the customer’s actual group structure, and a change deep in their hierarchy arrives as an unexplained membership churn.

Group to role mapping is your design problem. The provider sends group names. Your product has roles. Who maps them, where that mapping is stored, and what happens to a user in a group that maps to nothing are all decisions the specification does not make for you. The workable pattern is letting the customer’s administrator configure the mapping in your product, with an explicit default for unmapped groups.

Initial sync is a burst. A new customer with a large directory generates a large number of requests in a short window. Rate limits that are fine for steady state are not fine for onboarding, and the failure looks like a broken integration on the customer’s very first impression.

Deletion of a group is ambiguous. Does removing a group mean removing the roles it granted? Usually yes, but if a user held that role through two groups, removing one should not revoke it. Getting this wrong removes access from people who should still have it, which is a support escalation rather than a security incident, but it is a loud one.

Needs first-hand data: Load a directory of realistic size for your largest expected customer and measure the initial sync: total requests, wall-clock duration, peak request rate and whether your rate limits were hit. Then change one user’s group membership and measure the delay until the role change is visible in your product. Those two numbers determine whether onboarding feels instant or broken.

Why buyers discover this requirement late

SCIM almost never appears in the original product plan, and the reason is structural.

Self-serve customers do not need it. Small teams add users by hand and consider that fine. The requirement appears at a specific point: the customer is large enough to have an identity team, and that team’s mandate is that no application manages its own user lifecycle.

By then several decisions are already made. Your user model probably assumes users are created by signup or invitation, which is the opposite of externally managed lifecycle. Your roles may be assigned in your product rather than derived from a directory. You may have user records that exist in your system and not in the customer’s directory, and no defined answer for what should happen to them. Deletion may cascade to owned records, which is catastrophic when a DELETE arrives that was meant as a deactivation.

Retrofitting SCIM onto that is the real cost, and it is larger than implementing the endpoints. The endpoints are a week. Reconciling “users are created by invitation” with “users are created by the customer’s directory” is a data model change on a live product.

Two decisions worth making early, even if SCIM is far off.

Separate identity from membership. A person who authenticates is one thing. Their membership of a tenant with a role is another. If those are the same record, externally managed lifecycle is painful, because the directory owns one half and you own the other.

Never hard delete a user. Deactivate, keep the record, preserve the audit trail and the ownership of their work. This is good practice independently, and it makes the DELETE-versus-deactivate divergence a non-issue instead of a data loss incident.

The same foresight pays off across the rest of the enterprise checklist, which is covered in auth providers for B2B SaaS.

WorkOS

WorkOS sells enterprise features as an API, and directory sync is the clearest example of the model. Rather than implementing a SCIM server and handling per-provider divergence yourself, you integrate once with WorkOS, receive a normalised user and group representation over webhooks or an API, and let them absorb the differences between Okta, Entra, Google and the rest. For a team meeting this requirement under deal pressure, that abstraction is the product.

Pros

• Normalises provider divergence, so patch semantics, delete behaviour and attribute mapping become their problem rather than a per-customer workaround in your codebase
• Admin Portal gives the customer a self-serve configuration flow, which removes the setup call that otherwise scales linearly with every enterprise deal
• Directory sync and SSO come from one integration, and those two requirements almost always arrive together
• Webhook-driven events fit naturally into an existing application rather than requiring you to expose a public SCIM endpoint

Cons

• You depend on their normalisation, so a provider behaviour they have not modelled is something you wait for rather than fix
• Priced per connection, which means the cost scales directly with the number of enterprise customers, exactly as those customers become valuable
• It is a layer in front of your product rather than part of it, adding a dependency on the path where customer access changes propagate
• Less useful if you already run an identity platform that speaks SCIM natively, since you would be paying for translation you partly have

Best for: B2B SaaS teams who need directory sync and SSO shipped for a specific enterprise deal without building and maintaining per-provider handling.

Pricing: Metered per connected enterprise organisation, with directory sync and SSO connections counted as the billable unit rather than end users.

Okta

Okta is the identity provider on the other side of most SCIM integrations, which makes it the reference implementation in practice. If your endpoint works with Okta, it works with a large share of the market. Okta also publishes an integration network, and getting your application listed there involves conforming to their expectations, which is a meaningful engineering exercise and a meaningful distribution channel.

Pros

• The most widely deployed source of SCIM traffic, so conformance with Okta covers a large share of enterprise customers by itself
• Lifecycle Management provides mature provisioning with attribute mapping, transformation rules and per-application policy on the customer’s side
• Listing in their integration network makes your application discoverable and configurable by administrators without a support conversation
• Administrators get real visibility into provisioning status, which means failures are at least detectable by the customer

Cons

• Provisioning is licensed separately from core identity, so not every Okta customer has it, and “our customer uses Okta” does not mean they can provision
• Conformance to their expectations is a real project, and passing their validation is stricter than passing the specification
• Aimed at the enterprise buyer, so evaluating it from the application side means engaging with a customer’s licensing rather than your own
• Their behaviour defines the de facto standard, which is convenient until a smaller provider does something different and you find your assumptions were Okta-shaped

Best for: Understanding what your SCIM server must handle, and for enterprises who are the source rather than the target of provisioning. Okta alternatives covers the workforce versus customer identity split in detail.

Pricing: Enterprise licensing per user per month with lifecycle management and provisioning licensed as separate modules on top of core identity.

Auth0

Auth0, now part of Okta, approaches provisioning differently from its parent. Its strength is enterprise connections and extensibility through Actions rather than a packaged provisioning engine, which means SCIM-shaped requirements are often met by building on the platform rather than configuring a feature. The Organizations model gives you the tenancy structure that provisioning needs to write into.

Pros

• Organizations model gives per-customer tenancy with its own connections and membership, which is the structure provisioning requires
• Actions let you implement custom provisioning and lifecycle logic at defined points, covering requirements no packaged feature anticipates
• Strong enterprise connection support, so the SSO half of the enterprise requirement is well covered alongside
• Management API is comprehensive, so building a provisioning layer on top is a supported path rather than a workaround

Cons

• Provisioning is less of a packaged product here than at vendors built around it, so more of the work lands on you
• Enterprise connections and organisation features sit in higher tiers, so the capability arrives with a pricing step
• Custom logic in Actions becomes undocumented business rules that are hard to test and easy to break during an upgrade
• Product boundaries between Auth0 and Okta customer identity have shifted, which complicates long-horizon planning

Best for: Teams already on Auth0 who need provisioning to fit their existing organisation model and are willing to build the lifecycle logic themselves. Migration considerations matter if the cost curve becomes a problem later.

Pricing: Metered on monthly active users with enterprise connections and organisation capabilities gated to higher tiers and billed separately.

Frontegg

Frontegg builds identity around the administrative surface your customers expect to operate themselves, and provisioning fits that framing. SCIM support sits alongside self-serve SSO configuration, team management, roles and audit logs, all as embeddable components. The argument is that provisioning is only half of the enterprise requirement and the other half is the administration screens you would otherwise build.

Pros

• Provisioning arrives with the admin surfaces around it: user management, roles and audit logs are components rather than a build
• Customers configure SSO and provisioning themselves, which removes the per-customer setup call
• Native multi-tenant model means provisioned users land in a tenancy structure that already exists rather than one you retrofit
• Audit logging is built in, which is what customers actually ask for when they ask about deprovisioning evidence

Cons

• Embedded components carry the vendor’s UX assumptions, and deep customisation hits limits
• Provider coverage and normalisation depth is narrower than vendors whose entire product is directory sync
• Tight SDK coupling makes later migration heavier than a protocol-level integration would be
• Aimed at B2B account structures, so a product without that shape pays for machinery it does not use

Best for: B2B products that want provisioning, SSO and the customer-facing administration screens delivered as one package.

Pricing: Metered on monthly active users with tiers, and enterprise capabilities including advanced security and audit on higher plans.

Zitadel

Zitadel is an identity platform, available managed or self-hosted, whose organisations model maps reasonably onto the tenancy that provisioning needs. Its distinguishing property in this context is the event-sourced data model, which means every provisioning action is recorded as an immutable event. For answering “when exactly was this person deprovisioned and by what”, that is a stronger position than a mutable user row.

Pros

• Every lifecycle change is an immutable event, producing provisioning audit evidence structurally rather than through a separate logging feature
• Organisations give per-customer boundaries with their own identity providers and policies, which is the structure provisioning writes into
• Comprehensive management API means provisioning integrations can be automated fully, including tenant and role setup
• Self-hostable, so a customer with data residency requirements does not force a separate architecture

Cons

• Provisioning is one capability of a broad platform rather than its focus, so per-provider normalisation is thinner than at specialists
• The event-sourced model needs learning before you scale it, particularly projection behaviour under high write volume
• Smaller community, so unusual provider interoperability problems have fewer public answers
• Adopting it for provisioning alone means adopting an identity platform, which is a much larger commitment

Best for: Teams already using or planning to use Zitadel as their identity platform who want provisioning and audit evidence from the same system. Its operational shape is covered in self-hosted identity providers.

Pricing: Managed cloud metered on usage with a free tier, alongside a free self-hostable open source build and commercial support.

Keycloak

Keycloak is the most capable open source identity provider and the weakest option on this page specifically for SCIM. Its strength in user lifecycle is federation: LDAP and Active Directory synchronisation, which solves a related problem for organisations whose directory is on-premises. SCIM server capability has historically come from community extensions rather than the core, and that distinction is the important one.

Pros

• LDAP and Active Directory federation is first-class and genuinely good, which covers user lifecycle for organisations whose source of truth is a traditional directory
• No per-connection or per-user cost, which matters when provisioning integrations scale with your enterprise customer count
• Full control over the user data model and over how external lifecycle events map onto your own records
• Extension points let you implement exactly the SCIM semantics you need, including safe handling of delete versus deactivate

Cons

• SCIM support depends on extensions rather than core functionality, so you inherit their maintenance and their compatibility with Keycloak upgrades
• Per-provider divergence is entirely yours to handle, which is the specific work the commercial options exist to absorb
• No packaged customer-facing configuration surface, so enterprise administrators cannot self-serve their setup
• Operational weight is high for a system whose SCIM story you will partly be building yourself

Best for: Organisations already running Keycloak whose lifecycle source is LDAP or Active Directory, and who have the engineering capacity to own a SCIM layer on top.

Pricing: Free open source with no feature gating and no per-connection cost. The cost is infrastructure plus the engineering time to build and maintain provisioning behaviour the core does not provide.

Descope

Descope approaches enterprise readiness through its visual flow builder, extending the same model from authentication journeys into tenant configuration, SSO and provisioning. For a team whose constraint is engineering time rather than architectural preference, configuring provisioning behaviour rather than coding it is a genuine shortcut.

Pros

• Provisioning and SSO configuration are handled through the same visual model as authentication, so one mental model covers the enterprise checklist
• Tenant model supports per-customer configuration without a separate tenancy layer on your side
• Fast to a working enterprise integration, which matters when the requirement arrives attached to a deal deadline
• Self-serve configuration surfaces for customer administrators reduce the setup burden per deal

Cons

• Newer vendor, so long-term viability is a live consideration for a system in the path of customer access changes
• Provisioning depth and per-provider normalisation are behind the specialists whose entire product this is
• Logic living in the flow builder is portable only within their platform, which raises the cost of leaving
• Public evidence of large-scale provisioning deployments is thinner than for the established platforms

Best for: Teams already using Descope for authentication who need provisioning added without a second vendor or a second integration.

Pricing: Metered on monthly active users with free and self-serve tiers, and enterprise capabilities and support on negotiated plans.

SSOJet

SSOJet is a focused enterprise-readiness vendor in the same category as WorkOS: SSO and SCIM directory sync delivered as an integration layer so that the application team does not implement per-provider behaviour. The argument for a specialist here is narrow and real. Enterprise SSO and provisioning are a bounded, well-understood problem, and a vendor doing only that has no incentive to pull you into a broader platform.

Pros

• Scoped to the enterprise-readiness problem, so adopting it does not mean migrating your existing authentication
• Sits alongside whatever you already use for user authentication, which suits teams whose consumer login works fine and whose gap is enterprise features only
• Per-customer configuration surfaces remove the setup call that otherwise accompanies each enterprise deal
• Connection-based commercial model aligns with how enterprise requirements actually arrive, one customer at a time

Cons

• Smaller vendor than the established alternatives, so diligence on viability is warranted for something in the access path
• Less public implementation evidence and fewer community answers than the larger platforms
• A single-purpose vendor is another supplier to manage, which is friction if you would rather consolidate
• Provider coverage and normalisation depth need verifying against the specific identity providers your customers actually use

Best for: B2B SaaS teams who are happy with their existing authentication and need only the enterprise SSO and SCIM layer, without adopting a full identity platform.

Pricing: Metered per connected enterprise organisation rather than per end user, which keeps the cost tied to enterprise customers rather than total user count.

How to choose

Answer one question first: are you the SCIM client or the SCIM server? If your customers’ identity providers push users into your product, you are the server, and everything below applies. If you are an enterprise provisioning users into applications you buy, you are the client, and the relevant products are identity platforms with lifecycle management, which means Okta or its equivalents.

As the server, the decision comes down to three cases.

You need it for a specific deal, soon. Buy the abstraction. WorkOS or SSOJet, integrated once, with per-provider divergence absorbed by someone else. The per-connection cost is unambiguously worth it against the engineering weeks and the ongoing per-customer maintenance.

You already run an identity platform. Use what it gives you. Auth0, Frontegg, Descope and Zitadel all provide a path, and adding a second vendor for provisioning alone is rarely justified if your platform covers the providers your customers use.

You run your own identity infrastructure and have engineering capacity. Implement it yourself, and be honest that per-provider divergence and ongoing maintenance are the real cost rather than the endpoints. Keycloak sits here, with an extension you will own.

Whichever you pick, build the monitoring yourself. No product on this page will tell you that a specific customer’s connector quietly stopped firing, and that is the failure that matters.

Tool	Role	Absorbs provider divergence	Meter	Picks itself when
WorkOS	Abstraction layer	Yes, its core value	Per enterprise connection	You need it shipped for a named deal
Okta	Identity provider, the client side	Defines the behaviour	Per user, provisioning licensed separately	You are the enterprise, not the vendor
Auth0	Identity platform	Partly, extended with Actions	Per monthly active user	Already on Auth0 with Organizations
Frontegg	Identity plus admin surfaces	Partly	Per monthly active user	You want the admin screens too
Zitadel	Identity platform	Partly	Usage, or self-hosted	Audit evidence and self-hosting matter
Keycloak	Self-hosted IdP	No, you handle it	Free, infrastructure only	LDAP is the real source of truth
Descope	Identity platform	Partly	Per monthly active user	Already using Descope for auth
SSOJet	Enterprise-readiness layer	Yes	Per enterprise connection	You keep your auth and add enterprise features
SCIM (specification, not a product)	The contract	Defines the shape, not the behaviour	None	Never a choice, it is what providers speak

Needs first-hand data: Before signing with any abstraction vendor, test your two most common customer identity providers end to end through their integration: create, update, group membership change, deactivate and delete, with the deactivation timed to session termination. Record which of the five behaved differently between the two providers despite the abstraction. That residue is the work you are still doing yourself.

Frequently asked questions

Do I need SCIM if I already have SSO?

They solve different problems and enterprise buyers eventually want both. SSO handles authentication, so a person who exists in the directory can sign in. It does not create accounts ahead of time, assign roles, or communicate that someone has left. Just-in-time provisioning during SSO covers account creation reasonably well and covers deprovisioning not at all, because a departed user simply stops signing in and your record stays active indefinitely. That gap is precisely what the security questionnaire is asking about.

Can I just use just-in-time provisioning instead?

For creation, often yes, and it is much less work. For deprovisioning, no. JIT creates a user on first successful sign-in, which means your product never learns about anyone who leaves. The account remains active, retains its roles, and keeps any API keys or tokens it held. A common pragmatic pattern is JIT for creation plus SCIM for deactivation, which gets most of the value for less than half the implementation.

How quickly does deprovisioning actually take effect?

Three delays stack. The identity provider’s own detection and push interval, which varies by provider and configuration and is not always immediate. Your processing time, usually negligible. Then the one that dominates: session lifetime. If you mark a user inactive but only check that flag at login, an existing session keeps working until it expires. Terminating live sessions on deactivation is what makes the number match what the customer expects, and it is an implementation choice rather than anything the specification provides.

What happens when a SCIM DELETE arrives for a user who owns data?

This is the question to settle before your first integration, not during it. The safe answer is that DELETE means deactivate: keep the record, preserve ownership and audit history, and block authentication. A hard delete that cascades through owned records turns a routine offboarding into data loss, and because some providers send DELETE where others send a deactivation patch, you cannot infer intent from the verb. Treating both as deactivation makes the divergence harmless.

Should I build SCIM myself or buy an abstraction layer?

Build it if you have engineering capacity, a small number of identity providers to support, and you already run identity infrastructure that models tenancy properly. Buy it if the requirement arrived with a deal attached, if your customers use a broad mix of providers, or if nobody on the team will own the per-provider maintenance a year from now. The endpoints are not the cost. The cost is the long tail of provider-specific behaviour and the monitoring that tells you when one of them stopped working. The broader build-versus-buy calculation is in best authentication providers.

Related reading

• Best authentication providers for developers — the full category and the build-versus-buy arithmetic.
• Best enterprise SSO solutions for B2B SaaS — the authentication half of the same enterprise requirement.
• Best auth providers for B2B SaaS — multi-tenancy and the requirements that arrive with your first enterprise deal.
• Clerk vs Auth0 vs WorkOS — three different bets on how enterprise features should be delivered.
• Best self-hosted identity providers — running the IdP that provisioning writes into.
• Best log management tools — keeping the provisioning audit trail queryable when a customer asks for evidence.