WorkOS vs Clerk for SCIM: 3-Way Buyer Guide 2026

WorkOS vs Clerk for SCIM and enterprise SSO is a comparison of two identity products judged on SAML/OIDC login and on SCIM 2.0 directory sync — two separate buy criteria. This is not a payroll system. This is not an Okta replacement for your own employees. The page is published from the homepage. Neither vendor paid for inclusion.

SCIM 2.0 is the provisioning protocol enterprise IT expects for joiner, mover, and leaver, according to IETF RFC 7644 (2015), the HTTP protocol specification for SCIM. SSO (SAML or OIDC) answers "can this person sign in." SCIM answers "does this person still have a seat, a group, and a deprovision event." Buying one and assuming the other is how you ship enterprise SSO that still needs a CSV every Friday.

Median SaaS ARR per FTE: $145K according to ChartMogul (2024) SaaS Benchmarks for the $5-20M ARR band. Headcount-planning math is why you do not staff a custom SCIM adapter per directory if a product already exists. SCIM protocol: RFC 7644 according to IETF RFC 7644 (2015), which is HTTP-based provisioning, not a login button.

TL;DR: Choose WorkOS when Directory Sync / SCIM is a procurement gate and you will map dsync.user.created into your app. Choose Clerk when you want full-stack auth, Organizations, and user management first, then confirm the exact enterprise SSO and SCIM SKU on the contract. Stay on whichever already owns sessions if the only remaining work is a webhook to your billing seat. Orchestrate only when identity, billing, and the product database disagree on whether the user is active.

Note: live USTA pages that mention "clerk" in occupation-ROI titles are SOC occupation pages, not this Clerk product. This article is the identity vendor.

SCIM 2.0 is not the same buy as SSO

User lifecycle management is provisioning, updates, and deprovisioning from a directory of record. WorkOS Directory Sync (2026) documents SCIM plus HRIS connectors, Admin Portal setup, and events for directories, groups, and users. Clerk docs (2026) lead with authentication, Organizations, Billing, and UI components — enterprise SSO exists, but you must confirm SCIM/directory sync on the edition you buy rather than infer it from the login widget.

Okta's own SCIM guidance, according to Okta (2026), treats SCIM as the contract between an identity provider and the app. Your customer's Okta or Entra tenant is not your product. You still have to implement the app side.

G2 WorkOS (2026) and G2 Clerk (2026) are the review neighborhoods; do not treat a star average you did not open as a number on this page.

Adjacent SaaS ops: security-compliance automation, free-to-paid migration, subscription order management, and partner enablement. Those are not SSO.

Key Takeaways

• SSO and SCIM are separate RFPs; a SAML checkbox does not deprovision a leaver.

• WorkOS Directory Sync is built as ULM/SCIM for B2B apps; Clerk is built as full-stack auth with Organizations and Billing.

• RFC 7644 is the protocol enterprise IT will ask about; test against Okta and Entra, not only a happy-path SAML login.

• Public SCIM add-on prices are often quote-led; put connection count and MAU in the same email.

• Orchestrate seat and access holds only after a unique user key exists in IdP, app, and billing.

Who this WorkOS vs Clerk page is for

This page is for B2B SaaS founders, platform engineers, and IT-facing PMs who are losing enterprise deals on SSO/SCIM questionnaires and who can ship webhooks into an app that already has an organization object. Stack: your app plus Stripe or a billing system plus an identity product. Pain: manual invites, ghost seats, and security questionnaires you fail.

Red flags: you are a B2C consumer app with no organizations; Clerk or WorkOS already owns SSO and SCIM and the remaining work is copy; you will not store a directory user ID or name an owner for deprovision.

Weighted identity criteria

Weights assume a B2B product selling to companies that have Okta or Entra. A B2C Clerk shop should raise UI components and lower SCIM.

Normalized SSO and SCIM matrix

Scores from public docs checked 2026-09-06: 2 = first-party description of this job; 1 = adjacent, confirm SKU; 0 = not found. USTA column = first-party design numbers (1 hold, 1 recipe).

WorkOS wins the SCIM/ULM story on public Directory Sync docs. Clerk wins full-stack user management and Organizations. DIY SAML wins only if you will own every IdP quirk. USTA's 1s are a proposed seat hold, not an IdP.

Pricing and TCO for directory sync

Checked 2026-09-06. WorkOS SSO and Directory Sync are commonly sold per connection / usage; Clerk publishes self-serve auth tiers and enterprise add-ons. This page will not invent a per-MAU number that was not on the fetched docs. Example: 40 enterprise customers, 2 connections each (SSO + SCIM).

Ask for SSO connection price, SCIM connection price, MAU overages, and whether Admin Portal is included. A cheaper auth widget that cannot deprovision is not cheaper at $145K ARR per FTE.

WorkOS and Clerk profiles

WorkOS — best when SCIM is the enterprise gate

WorkOS Directory Sync is a set of APIs and IT-admin tools for user lifecycle management, hiding per-directory SCIM differences, according to WorkOS (2026). Best fit: B2B apps whose security questionnaire lists SCIM 2.0 and whose customers live in Okta, Entra, Google Workspace, or Workday. Limitations: you still build app-side role mapping; WorkOS is not your product authorization model. Implementation: Admin Portal, directory mapping, then consume events. Primary evidence: WorkOS Directory Sync docs. Disqualifier: you only needed a login box and Organizations UI.

Clerk — best when auth UX and Organizations are the product

Clerk is full-stack authentication and user management, including Organizations, Billing, and prebuilt UI, according to Clerk (2026). Best fit: teams that want sign-in, orgs, and billing metadata in one vendor, then add enterprise SSO. Limitations: confirm SCIM/directory sync on the contract; do not assume Directory Sync parity with WorkOS from the marketing homepage. Implementation: Clerk components, org model, then enterprise connections. Primary evidence: Clerk docs. Disqualifier: the RFP is SCIM-or-bust and you will not wait on a SKU confirmation.

DIY SAML — best only with a staffed identity engineer

You can implement SAML with open-source libraries and keep run history in your logs. Best fit: one IdP, one app, no SCIM. Limitations: every new directory is a project; RFC 7644 compliance is on you. Disqualifier: you are still answering enterprise RFPs with "we have Google login."

When NOT to use US Tech Automations: if WorkOS Directory Sync already provisions and deprovisions into your app of record, and Clerk or WorkOS already owns the session, do not add an orchestration layer to "do identity." If you have no organization object, buy the identity product first. If no one will approve a deprovision that kills a paid seat, do not automate it.

Zapier, Make, or n8n can subscribe to webhooks, retry, and keep audit logs. You still own idempotency of user IDs, the access-control model, retention of identity payloads, and the escalation when billing says paid and SCIM says terminated. A proposed US Tech Automations design would require a human hold before any paid-seat revoke and would write the decision back to the organization record.

A proposed joiner-mover-leaver hold

A $12M ARR SaaS team at about $145K ARR per FTE (roughly 80 people in that band) with 40 enterprise customers can treat WorkOS dsync.user.created as the joiner event that may create an app user, and the matching delete/deprovision event as a hold before Stripe seat quantity drops. The $12M, $145K, and 40 figures are a worked scenario; dsync.user.created is a real WorkOS Directory Sync event name used in their events model.

US Tech Automations could, as a configurable capability, listen for that event, match directory_user to organization_id, pause for a CS or finance reviewer when the org is on an annual contract, and emit a packet with IdP user ID, role, and seat impact. Prerequisites: WorkOS or Clerk webhooks, billing API, unique user key, human review before revenue-changing deprovision. Not a live customer result.

A second proposed path: a Clerk user.created event that lacks an organization membership waits in a hold instead of becoming a free personal tenant. The agentic workflow layer is the allowlisted route for that hold.

Identity glossary for B2B SaaS

• SSO: SAML or OIDC login. Not provisioning.

• SCIM 2.0: RFC 7643/7644 provisioning protocol.

• Directory Sync: WorkOS product name for ULM across SCIM and HRIS.

• ULM: joiner, mover, leaver.

• Organization: Clerk's shared-account primitive.

• Directory user: the IdP person mapped into your app.

• Admin Portal: customer-IT self-serve connection UI.

• Idempotency: one IdP user creates one app user, even if the webhook retries.

Okta and Entra tests that actually close the RFP

Enterprise IT will not accept a Google-login screenshot as SCIM. Stand up two test tenants: Okta and Entra. For each, complete SSO (SAML or OIDC) and then directory sync. Create five users, change a department on two, deprovision two. Your app must show the user in the right organization, with the right role, and then show access gone. If deprovision only hides the user in a UI while the API token still works, you failed.

Map groups to roles in a table you can email to the customer's IT admin. "We'll figure out roles later" is how you ship a joiner who lands in a global admin org. Clerk Organizations can be the tenant primitive; WorkOS Directory Sync can be the user feed. Do not dual-write both as systems of record for the same membership.

Price SSO and SCIM as separate connections on the quote. A $145K ARR-per-FTE shop that spends a quarter building a custom SCIM adapter has paid more than a year of vendor Directory Sync. DIY SAML libraries can keep retries and logs; they cannot hide the fact that every new directory is a project.

ARR band in the receipt: $5-20M according to ChartMogul (2024) SaaS Benchmarks, the same report as the $145K ARR-per-FTE figure. WorkOS Directory Sync docs still describe SCIM plus HRIS connectors across many directories — that breadth is the buy when the questionnaire lists Okta, Entra, Google, and Workday. Clerk still wins if the product need is sign-in UI and Organizations first — confirm the SCIM line item anyway.

Keep billing in the loop. A SCIM delete that drops a seat on an annual contract is a revenue event. That is the only reason a hold exists on this page.

Write the security questionnaire answers as facts you can demo, not as roadmap poetry. "SSO: yes, SAML and OIDC, Admin Portal for customer IT." "SCIM: yes, RFC 7644, Okta and Entra tested, deprovision revokes API tokens." If the second sentence is actually "Q3" you are not enterprise-ready, and Clerk vs WorkOS will not save you. The identity vendor can hide directory quirks. It cannot invent an organization object in your database.

Seat math belongs on the same page as connection price. Forty enterprise customers times two connections is eighty billed objects if the vendor sells that way. Ask. A self-serve Clerk plan that covers password users will not automatically cover those eighty objects. A WorkOS invoice that looked cheap at five customers will not look cheap at forty if Directory Sync is per-directory. Put MAU, connections, and Admin Portal on one email. If sales cannot answer in one email, you do not have TCO. You have a hope.

Deprovision tests must include the token. UI hidden plus live bearer token is a finding, not a pass. Movers (department or group change) must change the role in your app within the same day you will promise IT. If it takes a nightly job, write nightly in the questionnaire. Customers will ask.

G2 WorkOS (2026) and G2 Clerk (2026) remain review neighborhoods. They do not replace the two-IdP pilot. If you only test Okta, Entra will fail in week one of the first bank customer. If you only test happy-path create, the leaver will keep a seat through the annual invoice.

A proposed hold is still optional after that pilot. If billing and identity already agree, and a human already approves annual-contract deprovision, you do not need another queue. If they disagree, the queue is the product — and it is not an IdP.

FAQs

Does Clerk include SCIM if we buy Organizations?

Not automatically on every SKU. Clerk docs emphasize auth, Organizations, and Billing. Confirm directory sync / SCIM on the enterprise quote before you promise it in an RFP.

Why do enterprises ask for SCIM and SSO separately?

SSO signs the user in. SCIM creates, updates, and deletes the user from the directory. RFC 7644 is the provisioning contract. Tickets are not SCIM.

Is WorkOS a replacement for Okta?

No. WorkOS helps your app speak SSO and SCIM to the customer's Okta, Entra, or Google tenant. Your customer still owns the directory.

Can we ship SAML now and SCIM later?

Yes, and many teams do. Do not tell enterprise IT they are the same milestone. Price both connections.

When is Zapier enough for deprovision?

When the user is not a paid seat and a retrying webhook plus a log is the whole job. When deprovision changes ARR, add a named hold.

How should US Tech Automations sit next to WorkOS?

US Tech Automations should not become the IdP. A proposed path holds paid-seat deprovision after dsync.user.created / delete events until finance confirms the contract. See pricing for how that hold is scoped.