Clerk vs WorkOS (2026): B2B SSO, SCIM and Pricing Compared

Clerk is a full user management and sign-in layer that has added B2B features, and WorkOS is an enterprise-readiness layer (SSO, directory sync, an admin portal) that has added user management. If you want drop-in sign-in screens and organizations for a modern frontend, Clerk gets you there faster. If your main problem is making your existing app pass enterprise security reviews, with each customer’s IT admin connecting their own identity provider, WorkOS was built around that job. Since late September 2026 the gap has narrowed, because Clerk now offers self-serve Directory Sync and an SSO fallback of its own.

What is the difference between Clerk and WorkOS?

The simplest way to separate them is by where each started. Clerk began as a product for the people who sign in to your app: components for sign-up, sign-in and profile, plus sessions and user storage. WorkOS began as the missing piece between a SaaS app and its customers’ corporate identity providers: SAML and OIDC single sign-on, SCIM directory sync, and a hosted admin portal where a customer’s IT person sets it up without your engineers. Both now overlap in the middle, which is why teams that evaluate “enterprise-ready auth” end up comparing them.

What did Clerk change in September 2026?

Two releases in the last days of September add features that WorkOS has long offered.

On 30 September 2026 Clerk released self-serve Directory Sync. Before, Clerk’s team configured a directory connection in the Dashboard and handed the SCIM endpoint and token to each customer. Now the customer’s IT admin can set up provisioning from the Security tab of the organization profile component, next to self-serve SSO, including a Google Workspace flow in which the admin uploads a service account key and names a Workspace admin account. It requires Organizations and, in production, the Pro or Business plan plus the B2B Authentication add-on (Clerk, “Self-serve Directory Sync” changelog, 2026).

On 29 September 2026 Clerk released SSO bypass: users on an allowlist can request a one-time code by email from a “Can’t use SSO?” option, which keeps people working if the customer’s identity provider has an outage or the connection is misconfigured. Only users with a verified email on a domain served by the connection can be allowlisted, Clerk does not check whether the address still exists in the customer’s directory, and each use is recorded in the application logs (Clerk, “SSO bypass” changelog, 2026).

The practical effect is that a self-serve admin experience for SSO and provisioning is no longer a reason on its own to pick WorkOS over Clerk. The bypass allowlist also carries a risk to manage: because Clerk does not check whether an allowlisted address still exists in the customer’s directory, a leaver who stays on the list could still sign in with an emailed code, so someone has to prune it when people leave (the Clerk documentation describes it as an allowlist that you manage per connection).

How do they compare for B2B SSO and SCIM?

The capabilities that matter in an enterprise deal are the same ones for both vendors:

• Who configures the connection. Enterprise customers want their own admin to do it, with clear instructions, and not file a ticket with your team. Both products now offer a self-serve path, so compare how much of the flow you can brand and how well the setup instructions cover the major providers.
• Multiple connections per organization. Larger customers sometimes have more than one identity provider, for example after an acquisition. WorkOS bills and models each connection separately, so a customer with two providers has two connections, and Clerk meters extra enterprise connections beyond its plan allowance.
• Provisioning and deprovisioning. SCIM is what removes a leaver’s access automatically. Our explainer on JIT provisioning vs SCIM shows why many security teams insist on it.
• Audit logs and support. Customers will ask for sign-in events and a security contact. WorkOS sells audit logs as a separate product, and Clerk records sign-in events in its application logs (including each SSO bypass), so decide which of those your customers will accept as evidence.
• Data residency and compliance. If a customer needs a particular region or certification, confirm it on the vendor’s trust pages before you commit, since these differ by plan and change over time.

How do the pricing models differ?

We are comparing models, and not quoting prices, because they change and depend on your contract.

Clerk meters its plans on monthly retained users, adds a B2B Authentication add-on for production organization features, and meters additional enterprise connections beyond what a plan includes (Clerk, pricing page). WorkOS prices SSO and directory sync per connection, so one organization with two identity providers is two connections, while its AuthKit user management has a large free tier before per-user charges apply (WorkOS, pricing page). Check both pages for the current limits. The practical difference is where growth shows up on the bill:

• Clerk cost grows with retained users and, once you pass the included allowance, with enterprise connections, so it is comfortable while both numbers are modest.
• WorkOS cost grows mainly with the number of customer connections, so it suits a large user base with a smaller set of enterprise customers whose contracts can carry the cost of their own connection. It gets heavier when you give SSO to a long tail of small customers.

To decide, count two numbers: how many people you expect to sign in each month, and how many separate customer identity providers you expect to connect, now and in a year.

What about lock-in and exit?

Whichever you choose, the exit work is the same: export users, handle passwords, and ask each customer’s admin to update their identity provider connection. Keep your application on standard OpenID Connect or SAML and avoid vendor-specific claims where you can. And keep your own record of which customer uses which provider and which attribute mappings, since you will need that to rebuild the connections elsewhere. For a worked example of leaving a hosted service, see our guide to migrating from Clerk to Keycloak.

When does neither fit?

If you want SSO, SCIM and organizations without paying per MAU or per connection, standards-based Keycloak is the other route. It has organizations, SAML and OIDC identity brokering and home realm discovery. Its native SCIM API (supported since 26.8) works per realm and is inbound only, so per-customer provisioning that mirrors Clerk or WorkOS means a realm per customer or an extension (see Keycloak 26.8 native SCIM). Skycloak runs Keycloak as a managed service priced on infrastructure rather than users or connections. The cost is that you assemble the sign-in screens and the customer-facing setup flow yourself or with the Keycloak tooling, so it suits teams that value the ownership and have the engineering time. Further reading: Clerk vs Auth0, Keycloak vs Clerk, Keycloak vs WorkOS, home realm discovery with Keycloak organizations, and our pages for B2B SaaS and SCIM. If you are shortlisting, Clerk alternatives and WorkOS alternatives cover more options.

How should a B2B SaaS team decide?

• You need sign-in screens and sessions as well as enterprise features. Clerk covers both in one product, and the 2026 releases close most of the enterprise gap.
• You already have your own sign-in and only need enterprise SSO and SCIM. WorkOS is designed to be added to an existing app for that purpose.
• You expect many small customers on SSO. Model per-connection cost carefully.
• You expect a few large customers and a big consumer-style user base. Model the per-user side carefully.

Run both through the same three scenarios: today, with ten enterprise customers, and with ten times as many users. Then make the choice on what the numbers show.

FAQ

Is WorkOS or Clerk better for B2B SSO?

It depends on what you already have. If you also need sign-in screens and sessions, Clerk covers both, and if you only need the enterprise layer on top of your own sign-in, WorkOS is built for that. The workos vs clerk question is mostly a question of scope.

Is Clerk a replacement for WorkOS?

For many teams it can be, since Clerk now offers SSO, Directory Sync with a self-serve admin flow, and an SSO fallback. WorkOS remains a better fit if you already have your own sign-in and only need the enterprise layer on top of it.

Does Clerk support SCIM?

Yes. Directory Sync (SCIM) reached general availability in April 2026, added Google Workspace in August 2026 (Clerk, “Google Workspace Directory Sync” changelog, 2026), and gained a self-serve setup flow for customer IT admins on 30 September 2026.

Does WorkOS include user management?

Yes, through AuthKit, which provides hosted sign-in and user management. WorkOS started with the enterprise features and added user management afterward.

What is SSO bypass?

It is a fallback that lets selected users sign in with an emailed one-time code when their company’s identity provider is unavailable. Clerk shipped it on 29 September 2026, and it needs an allowlist that you keep current as people leave.

Is there a WorkOS alternative that is not billed per connection?

Yes. Keycloak, which is open source, includes SSO, identity brokering and organizations, plus a native SCIM API that works per realm, and it can be run yourself or as a managed service.