Open-source alternative to Clerk enterprise SSO

Open-source alternative to Clerk enterprise SSO connections: the short answer

Customers now ask for single sign-on as a condition of buying, and on Clerk each enterprise connection is a separate line item. The main open-source paths are Keycloak as a broker for customer identity providers, and Ory Polis for SAML SSO and SCIM directory sync. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and its identity brokering lets your application trust one realm while customers authenticate against their own Okta, Entra ID or other provider. Ory Polis covers the narrower job of SAML and OIDC single sign-on plus SCIM provisioning, and it is a good fit when you want that layer without a full identity platform.

The choice depends first on whether you keep Clerk for application login. If Clerk stays for sign-in and session handling, the open-source component sits beside it and handles only the customer connections, which means you must design how the two sets of tokens and user records are linked. If you move application login too, the decision widens to whether a single self-hosted system should own both login and enterprise connections. Confirm the current Clerk feature set for SAML and SCIM with Clerk before you decide, since the boundary between what you still pay for and what you run changes with that answer.

Before committing, confirm three things in your own environment: which identity providers your largest prospects use, whether they need SCIM provisioning or only login, and who on your team will run the service, since Keycloak is a Java server with its own upgrade and high availability work. Ask any implementation partner for a written scope that names the connections, the directory sync requirements and the operating model. The cost of each path comes from people, infrastructure and support, not from a license fee, so treat that scope as the basis for comparing the options.

Which open-source component covers each Clerk SSO capability

This table maps each enterprise SSO capability you pay Clerk for to the open-source component that can cover it, with a column for the gaps you should confirm. Read each row against your own customer contracts, because the free editions of Ory and authentik differ from their enterprise tiers. Keycloak is the broadest single option, while Ory Polis and Ory Kratos split the work between SAML and SCIM and the login experience.

Clerk capability	Open-source component	Gap or condition to confirm
Enterprise SAML and OIDC connections	Keycloak brokers customer SAML 2.0 and OpenID Connect identity providers per realm or organization	Confirm how many connections your realm design needs and how your team will automate their creation
Customer identity provider brokering	Keycloak identity brokering to external IdPs, with Ory Polis as an SSO bridge for SAML and OIDC	Ory Polis is a separate service you deploy and operate alongside your app login
SCIM directory sync	Ory Polis provides SCIM directory sync. authentik free edition includes SCIM; Keycloak and ZITADEL also list SCIM support	authentik's free edition supports SCIM with community support only. Confirm each vendor's current SCIM feature set in your environment
Application login UI	Ory Kratos offers headless APIs, so your team builds the login and account screens; Keycloak provides a hosted login page with theming	Clerk's prebuilt components do not carry over. Budget engineering time for the UI you choose
Organizations and multi-tenant admin	Keycloak realms and groups; Ory Kratos organization login is an enterprise feature in the Ory Kratos README	Ory's SAML, SCIM and organization login need the Ory Enterprise License. Confirm this against your requirements
Audit and admin console needs	Keycloak admin console and event logging; authentik admin interface; Ory components expose admin APIs	Confirm log retention, export and alerting in your SIEM, since these are not uniform across components
Protocol coverage for customer SSO	Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0; Ory Hydra covers OAuth 2.0 and OpenID Connect	Hydra does not provide SAML. Route SAML customers through Keycloak or Ory Polis

Keycloak, Ory Polis and authentik compared for customer SSO

Enterprise SSO is where per-connection fees usually add up, so the choice here is about which self-hosted component should broker your customers' identity providers. The three options below handle that job in different ways, and each one changes how much of the login experience you must build and operate yourself.

Keycloak for brokering customer IdPs

Keycloak is an Apache 2.0 licensed identity server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, with identity brokering and user federation to LDAP and Active Directory. It is a Cloud Native Computing Foundation incubating project. It fits teams that want one self-hosted system for customer SSO, brokered IdPs and a built-in login UI. The main trade-off is operating a Java service: you own clustering, database sizing, upgrades and a synchronously replicated database for high availability. Ask your team to confirm how it handles per-tenant realms before you commit to the design.

Ory Polis for SAML and SCIM

Ory Polis is an Apache-2.0 service that adds SAML and OIDC single sign-on and SCIM directory sync to an application. It is designed to sit beside an existing login system rather than replace it, so you keep your current authentication and add enterprise connections in front of it. It fits SaaS teams that already run a login they like and need enterprise connections added. The trade-off is that you still run a second service, and you must confirm how it hands identities back to your application. Note that Ory's own README places SCIM and SAML in its enterprise tier when used with Kratos, so check which features your chosen build includes.

authentik for a single identity service

authentik has an MIT licensed open-source core that supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. Its enterprise directory sits under a separate authentik EE License, and its free edition is supported by the community only. It fits teams that want one platform for workforce and customer SSO, with a visual flow designer and no separate SSO service. The trade-off is licensing: features such as Microsoft Entra ID and Google Workspace integrations and ticket-based support are in the paid tier. Confirm which connectors your customers need before you rely on the free edition in production.

Cost to run each option

Each option costs more in people than in licenses, since all three are open source. Your costs are the servers or Kubernetes capacity, the PostgreSQL database, the engineers who upgrade and patch, and any paid support contract you choose. Keycloak tends to need the most operating capacity, Ory Polis adds a service to run next to your login, and authentik costs depend on whether you need enterprise features. Ask any implementation partner for a written scope that lists each of these components, who operates them, and what recurs each year.

How Keycloak brokers customer identity providers

The core pattern is simple: your SaaS application trusts one broker, a single Keycloak realm or client, and Keycloak federates to each customer's SAML or OIDC identity provider. Your app never speaks SAML to each customer directly. Each enterprise connection becomes an identity provider entry inside the broker realm, and Keycloak handles the protocol exchange, the redirects and the token issued back to your application. This is the part Clerk bills per connection, so the question to answer early is who will create and maintain those entries, and how often customers will ask for them.

Per-customer configuration is the main recurring cost driver. Each identity provider needs its own metadata, signing certificates, client details and attribute mappings, and each of those must be re-checked when a customer rotates a certificate or changes its directory. Mappings matter most for users who already exist. If a person already has an account in your app and then signs in through a customer's identity provider, you must decide whether Keycloak links that login to the existing user by a stable attribute such as email, or creates a second account. Test the linking rules with a real pilot customer before you promise SSO to others. For managing this as code, the Keycloak Operator provides KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources, which keep client definitions in version control. The Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, so plan a review step for each Keycloak release.

When Ory Polis adds SAML SSO and SCIM directory sync

This section applies when the team keeps its current application login and only needs enterprise connections. Ory Polis handles the SAML and OIDC single sign-on layer and SCIM directory sync, so customer IdPs such as Okta or Microsoft Entra ID can sign users in and push user provisioning changes, while the app's own session model stays as it is. Polis is a separate service with its own database and configuration, so it is a second system to run next to the existing login stack, not a setting inside it.

The hard part is the handoff. Polis returns an authenticated identity to your application, and your backend must map that identity to the existing user record, create or link the session, and handle logout and re-authentication. Your team owns the mapping of SCIM attributes to your user model, deprovisioning rules when a directory removes a user, tenant isolation so one customer's connection cannot sign in to another's organization, and the secrets and certificates for each connection. Plan testing against each IdP you expect customers to use, and confirm which attributes and group claims each one sends.

Ory's README states that SCIM, SAML and organization login are enterprise features not available in the open source version, and Ory's Enterprise License covers them with support terms. Confirm with Ory which Polis features are open source under Apache-2.0 and which require a commercial agreement before you commit to a design, and ask for the licensing terms in writing, including whether an Enterprise License build is a drop-in replacement for your current deployment. Price the license, the Polis operations and your engineering time together, since each is a separate cost.

Running SSO alongside Clerk, or replacing Clerk for app login

This path leaves Clerk as the application's login and session provider, and moves only the customer SAML and OIDC connections to a self-hosted broker. Keycloak can broker customer identity providers, so each enterprise customer's IdP trusts Keycloak and Keycloak trusts Clerk, or your app, as a downstream client. Ory Polis is a narrower option that handles SAML and OIDC single sign-on and SCIM directory sync, which suits teams that only need the connection layer.

Session handoff: The app keeps its Clerk session. Enterprise logins return through the broker, and your backend must map the verified identity to a Clerk user before it creates a session. Confirm how Clerk accepts that mapping for your framework.
Authoritative user store: Clerk stays the record for application users, while the broker holds only the federated identity links. Decide in writing which system wins when an attribute differs, such as email or name.
Organization mapping: Map each customer's IdP tenant to one Clerk organization ID. Store that link in your own database so a changed domain or renamed tenant does not break access.
SCIM provisioning: If customers expect directory sync, confirm whether Polis or Keycloak will push user changes into Clerk, and who deprovisions users when a customer removes them.
Cost driver: Clerk per-connection fees disappear for the moved connections, but you pay for the broker's hosting, database and on-call work.

Before cutover, test a deprovisioned user, a user with two IdPs and a customer whose domain changes.

Moving enterprise connections off Clerk without breaking customer logins

This sequence moves each customer's SAML or OIDC connection to a self-hosted broker one tenant at a time, so every enterprise customer keeps signing in throughout the change. The output is a tested, per-customer cutover record and a retired Clerk connection for each account.

Inventory every enterprise connection in Clerk
Engineering and the account owner list each enterprise SSO connection in the Clerk dashboard, with the customer organization it belongs to, the protocol (SAML or OIDC), the customer's IdP vendor, and the attribute mappings and domains in use. Record which connections have Directory Sync enabled, since SCIM provisioning needs its own cutover plan. Confirm the exact fields Clerk exposes for connections with Clerk support, because the dashboard and API may differ. The output is a spreadsheet with one row per connection and a named owner for each customer contact.
Export users and organizations from Clerk
An admin with dashboard access runs the Clerk user export, which Clerk documents as including hashed passwords. Pull organizations, memberships and user metadata through the Clerk API as well, because the dashboard export may not carry every field you need. Treat app login and enterprise SSO as separate concerns: customers who sign in through their company IdP do not depend on a Clerk password, but local app accounts do. Store the exports encrypted and limit access. The output is a verified export with row counts that match the Clerk dashboard.
Stand up Keycloak or Ory Polis in your environment
The platform team deploys Keycloak in your own cloud account or data center, or deploys Ory Polis if you only need SAML and OIDC SSO with SCIM directory sync and will keep app login in Clerk for now. Configure a production database that Keycloak supports, such as PostgreSQL, and set up TLS, backups and monitoring before any customer touches the service. Review the Keycloak Operator guidance if you run on Kubernetes, and choose manual approval for operator updates. The output is a non-production environment that passes a health check and a documented restore test.
Recreate each connection with customer IdP metadata
For each connection, the engineer creates a matching identity provider in the new broker and loads the customer's metadata, such as the SAML metadata XML or the OIDC discovery URL, which the customer supplies. Map the claims or assertions your application relies on, including email, name and organization or group attributes. Keep the Clerk connection active during this step so nothing changes for the customer yet. The output is a configured connection per customer that matches the inventory row.
Run parallel logins with test customers
Ask two or three willing customers, or internal test accounts that sit in each customer's IdP, to sign in through both the existing Clerk connection and the new broker on a staging copy of your app. Compare the resulting user records, roles and tenant mapping, and check that session lengths, logout and error pages behave as expected. Keep a log of every discrepancy and fix it before the next test. The output is a signed-off test record for each protocol and IdP vendor in your inventory.
Cut over one customer at a time
Schedule each cutover with the customer, switch the application's routing for that organization to the new broker, and ask the customer to sign in and confirm access to their data. Keep the Clerk connection in place until the customer confirms, so you can roll back by switching routing again. Disable the Clerk connection only after a successful sign-in and a short watch period agreed with the customer. The output is a cutover log that records the date, the tester and the rollback path for each customer.
Retire Clerk connections and confirm the record
After every customer is cut over, remove the Clerk enterprise connections and confirm that no traffic still reaches them in Clerk's logs or in your application logs. Verify that the broker's audit records cover each login, and archive the export and the cutover log under your retention rules. Ask Clerk to confirm how long data remains after connections are deleted and whether any billing for connections stops at deletion. The output is a closed inventory where every connection is marked moved, tested and removed.

What does it cost and what does the work need from us?

What are the cost components of running Keycloak or Ory in place of Clerk enterprise connections?

The cost has five parts: infrastructure to run the identity servers, a PostgreSQL database that is replicated for availability, the internal team's time for operations and upgrades, support contracts if you buy them, and a one-time migration and testing effort. Keycloak is licensed under Apache 2.0, so the software itself carries no license fee. Ory's open-source components are also Apache-2.0, but features such as SCIM, SAML and organization login are enterprise features in the Ory Enterprise License, so those lines need their own quote. Ask for each component as a separate line item so you can compare it with your Clerk invoices.

Which costs are one-time and which recur every year?

One-time costs include the design of the connection model, the migration of existing customer SSO configurations, testing against each customer identity provider, and documentation and runbooks. Recurring costs include servers and database capacity, backups, monitoring, security patching, upgrades, on-call staffing and any support or enterprise license subscription. Connection setup for new customers also recurs, because each new enterprise customer needs its identity provider configured and tested. A written quote should separate the one-time project from the monthly or annual run costs.

What makes the cost go up as we add more SSO connections?

The main drivers are the number of customer identity provider connections, the volume of directory sync events from SCIM, the number of realms or tenants you isolate, and how much high availability you need. Each additional connection adds configuration, testing and troubleshooting work, even though the software license does not change. Directory sync volume raises database load and makes monitoring more important. High availability needs a synchronously replicated database and more nodes, which adds infrastructure and operating effort. Ask the vendor or partner to price these drivers separately so you can see how the bill changes at your expected customer count.

Can our team run Keycloak or Ory on its own?

A team with Linux, container and PostgreSQL experience can run Keycloak in-house, but it must own upgrades, database migrations, certificate handling, monitoring and incident response. Keycloak's documentation recommends manual approval mode for Operator updates to avoid unintended upgrades, which signals that someone must review each change. Ory's open-source edition is suited to evaluation and development, and its own documentation says it may accept upgrade downtime and does not guarantee CVE patching. Be honest with yourself about on-call coverage and whether you have one or two people who can own the system long term. An external partner can take on the build and handover, with ongoing support as a retainer.

How long does a migration take, and what sets the timeline?

The timeline depends on scope, not on a fixed figure. The main variables are how many customer SSO connections must be moved or re-tested, whether you need SCIM directory sync, how many user records and password hashes must be transferred, how complex your Clerk organization model is, and whether you need high availability from the start. Customer coordination often takes longer than the technical work, because each enterprise customer must confirm its identity provider settings. Ask for a written scope with milestones, and for the assumptions behind each milestone, before you agree a schedule.

How often does Keycloak release, and how should we plan upgrades?

Keycloak 26.8.1 is the current release, published October 13, 2026. According to the Keycloak blog from October 2024, since Keycloak 26.0 the project plans four minor releases a year and a major release every two to three years, and breaking changes in a minor release are opt-in. That cadence means you should schedule regular upgrade windows, test each release in a staging environment that matches production, and check the upgrading guide before each change. Database schema migrations run automatically at startup by default, but large deployments can apply them manually. If you use the Red Hat build of Keycloak, confirm its version and support window with Red Hat.

What should we ask for in a written quote for this migration?

Ask for a fixed scope listing each deliverable, such as the realm design, the identity provider connections, the SCIM sync configuration, the migration of users and password hashes, testing, documentation and handover. Request the assumptions behind the price and timeline, including the number of connections, expected user volume and whether high availability is included. Ask which items are one-time and which recur, what support or retainer terms apply, how upgrades are handled, what happens if a customer identity provider needs extra work, and which third-party licenses such as Ory Enterprise License fees are excluded. Confirm acceptance criteria and who signs off each milestone.

What to confirm with vendors before you commit

Before you commit to a design, confirm in writing which SSO and provisioning features each open-source edition actually ships. The SCIM and SAML availability differs by project and by edition, and the answer should come from the current documentation or the vendor, not from a feature list you saw earlier. For Ory, confirm the scope of the Ory Enterprise License: the Ory Kratos README places SCIM, SAML, organization login and CAPTCHAs among enterprise features, while Ory Polis covers SAML and SCIM directory sync. Ask which of these you would need to license, whether Ory Polis is supplied under the same terms as the other Ory open-source components, and what support and CVE patch commitments come with each option.

For authentik, the open-source core is MIT licensed, but the directory features sit under a separate EE License. Ask the vendor which directory connectors, including Google Workspace and Microsoft Entra ID, fall under that license, whether a self-hosted deployment may use them without an Enterprise subscription, and what the license permits when you host it for several customers. For Keycloak, check the database support matrix for the exact release you plan to run, since supported PostgreSQL and other database versions change between releases. Also confirm your upgrade approach, because the Keycloak Operator documentation recommends manual approval mode for operator updates.

Finally, list every customer identity provider your sales team has promised and test each one against a staging realm or tenant before you quote a go-live date. Record the protocol version, attribute mappings, signing algorithms, certificate rotation, and whether the IdP needs SCIM group push or only just-in-time user creation. Any feature that a customer requires but that is not yet tested should be marked as an open risk in the scope of work. Ask your implementation partner and the vendor to confirm support for each item in writing, so the gaps are known before the first enterprise contract depends on them.

How DeployOpen scopes and delivers customer SSO on open-source identity

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For B2B customer SSO, the work centers on brokering customer identity providers, testing each SAML or OIDC connection and handing your team a runbook for onboarding future customers.

How we scope

Inventory which customer identity providers, protocols and directory sync needs apply to your product today.
Confirm whether Keycloak brokering, Ory Polis or a combination fits your connection count and enterprise feature needs.
Agree deliverables, timelines and responsibilities in writing before any work starts, since engagements are fixed-scope.

How we build

Deploy the chosen identity platform in your infrastructure with a production database, high availability design and secrets handling.
Configure realms or organizations, identity provider brokering, attribute mappings and SCIM provisioning for your test customers.
Run security testing against login flows, token handling and connection onboarding before any customer traffic moves.

How we hand over

Deliver architecture diagrams, configuration records, backup and restore procedures and upgrade guidance tied to your environment.
Document the steps your team follows to add and test a new customer SSO connection without DeployOpen involvement.
Provide evidence and control documentation that your own auditors can review, noting that DeployOpen does not issue audit reports.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer, scoped separately from the build.
Plan upgrades with your team, including manual approval of operator updates where Kubernetes deployment is used.
Confirm with your vendor which enterprise features, patch commitments and support levels apply to your chosen edition before go-live.

Open-source alternative to Clerk enterprise SSO connections