Open-source alternatives to Okta

Which self-hosted Okta alternative to shortlist

Keycloak, authentik and ZITADEL each cover the core workforce SSO job of issuing OIDC and SAML sign-ins for internal applications. They differ in licensing, support model and how they handle directory federation, so the shortlist should follow your application mix and your appetite for paid enterprise tiers.

How Okta workforce capabilities map to open-source options

This table compares the main Okta workforce capabilities with the open-source platforms most often considered as replacements, and flags where your own testing must confirm coverage. Read each row against your app inventory and directory layout, because a yes in one platform can still hide a gap in a specific protocol feature, factor type or policy. The main takeaway is that SSO and directory federation map well to Keycloak, authentik and ZITADEL, while MFA policy depth, lifecycle automation and audit reporting need explicit validation before cutover.

Which Okta replacement fits your environment

How Keycloak brokers LDAP and Active Directory logins

What running self-hosted Okta alternatives costs over several years

This table separates the cost of a self-hosted Okta alternative into its components, marking which items are one-time and which recur, and what drives each. Use it to build a request for quotes and a multi-year model, since no open-source platform fee is charged and the real spend sits in infrastructure, people and support. The main takeaway is that tier choice, user count and upgrade cadence move the total more than the license itself.

What you give up when you leave Okta and how teams work around it

Moving workforce SSO off Okta trades a managed service for components your team operates. The cards below cover the gaps that usually surface during planning, with a workaround for each and the points to confirm against the exact product version you deploy.

How to move users, apps and MFA off Okta step by step

This sequence moves workforce sign-in from Okta to a self-hosted platform in controlled stages, so each application is proven before Okta is switched off. It produces a verified user migration, a tested set of applications and a documented decommission record.

1. Inventory applications, protocols and directory links

   Your identity team lists every application that signs in through Okta, with its protocol (SAML 2.0, OIDC or OAuth 2.0), its owner, its login URL, the claims or attributes it expects and any LDAP or Active Directory connection Okta uses for user sourcing. Application owners confirm the list, and the inventory also records where MFA is enforced through Okta policies and which apps rely on SCIM provisioning. The step is done when every app has a row with an owner and a protocol, and when the team agrees which apps are in the first pilot.

2. Export the active user list

   Okta documents three ways to pull a list of active users: the Password Health report CSV in the Admin Console, the community Rockstar browser extension, or the List Users API with a filter. For a repeatable migration, the List Users API is the option most teams script, because it can be rerun and filtered to active accounts. The export contains profile attributes only. Passwords and enrolled MFA factors do not come out in this export, so treat the file as an identity list, not a credential backup. The step is done when the record count matches what the Admin Console shows for active users.

3. Map attributes and decide how users load

   Map each Okta profile attribute to the target identity model, for example login name, email, first and last name, department and manager, and any custom attributes that application claims depend on. Decide whether users are loaded by CSV import, by scripted calls to the target administration API, or by federating an existing LDAP or Active Directory source, which Keycloak supports through built-in user federation. Confirm with the target platform's documentation how each attribute is stored and whether it can appear in tokens. The step is done when a mapping document is signed off and a test import of a few accounts shows the expected attributes.

4. Pilot with one or two applications

   Choose one or two low-risk applications that use OIDC or SAML and stand up the target realm or instance for them alone. Users in the pilot group sign in to the new platform while everyone else stays on Okta. The team tests login, logout, group or role claims, session timeouts and the MFA prompts users will see. Passwords are not carried over, so pilot users set new passwords or complete a first-login reset. The step is done when the pilot group has signed in successfully for a full working cycle and the issues log is empty or each open item has an owner.

5. Re-enroll MFA and communicate password resets

   Because MFA enrollments usually do not carry over with the user list, plan re-enrollment before the broader cutover. Prepare user communications that explain the new sign-in page, the new password reset path and how to register authenticators again, and set up help desk scripts for identity verification before a reset or factor reset. Confirm with the target vendor exactly which authenticator types it supports, such as TOTP, WebAuthn or hardware keys. The step is done when the help desk has a verified reset procedure and the communication has been reviewed by security and HR.

6. Run in parallel, then cut over application by application

   Keep Okta active while more applications move to the new platform in waves. For each application, update the redirect URIs, client secrets or SAML metadata, test a sign-in end to end and then switch the application to the new identity provider. Keycloak's realm export is documented as a way to move configuration between environments, but its documentation warns of limitations as a backup and restore method and says all nodes must be stopped while the export or import runs, so plan that outage window in advance. The step is done when each wave has a signed-off test record and no application still depends on Okta for sign-in.

7. Decommission Okta and retain evidence

   Once every application has cut over, disable Okta sign-in, revoke the integration tokens and API keys, and remove any SCIM or directory agents that still point at Okta. Keep the Okta audit logs, the export files and the cutover records under your retention policy, and confirm your contract terms for data return or deletion with Okta. Your compliance team records the final state, including how access reviews and logging now work on the new platform. The step is done when no Okta tenant is in use for authentication, the retention record is filed and the contract exit is confirmed in writing.

Questions buyers ask before replacing Okta

What changes for your users and help desk during cutover

How to decide between Keycloak, authentik and ZITADEL

This sequence narrows the three self-hosted candidates by the requirements that are hardest to change later, from directory and protocol needs through to skills and a pilot. It ends with a decision record that the platform team and security owners can sign off before any migration work starts.

1. Map directory and federation needs

   Start by listing where your users live today: Active Directory forests, LDAP directories, HR-driven provisioning and any Okta-side directories or groups. Identify who owns each source and whether the new platform must read from it, write to it or only sign users in against it. Keycloak has built-in user federation with existing LDAP and Active Directory servers, and FreeIPA can form mutual trusts with Active Directory, so note whether you need a directory service in addition to an SSO layer. Confirm the output with your directory owners. Done means a written table of user sources, the direction of sync and the group structures each application depends on.

2. Inventory every application and its protocol

   Export your Okta application list and record, for each app, whether it uses SAML 2.0, OpenID Connect, OAuth 2.0, SCIM provisioning, LDAP bind or a forward-auth proxy. Mark apps where the vendor documentation limits the supported protocols or where the team that owns the app is unknown. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0. authentik's free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. ZITADEL supports certified OIDC, SAML 2.0, SCIM 2.0 and LDAP. Confirm each candidate against your real list in a test tenant rather than from marketing summaries. Done means a protocol matrix in which every application maps to at least one candidate or is flagged for a gap decision.

3. Assess multi-tenant and organization needs

   Decide whether this deployment serves one workforce or several organizations, subsidiaries, or customer-facing tenants. A single-workforce deployment usually has simpler tenancy requirements than a platform that must keep data and policies apart for many customers. ZITADEL structures tenants as Identity System, Organizations and Projects, with data and policies isolated at several levels, which suits multi-tenant customer identity. Keycloak realms provide separation, though you should confirm the model fits your administration boundaries. Done means a short statement of tenancy, administrator boundaries and the number of realms or organizations you expect to run.

4. Compare license, support and edition requirements

   Record your licensing constraints and support expectations before you compare features. Keycloak is licensed under Apache 2.0 and is a CNCF incubating project. authentik's core is MIT licensed, but its enterprise directory is under a separate authentik EE License, and features such as privileged access management, Google Workspace and Microsoft Entra ID integrations sit in the Enterprise edition. ZITADEL uses AGPL-3.0 with Apache 2.0 and MIT exceptions for specific directories, so have legal review how AGPL terms apply to your use and any modifications. Ask each vendor which support tiers include SLAs and which features are paid. Done means a legal sign-off note and a list of features you need that sit behind a paid edition.

5. Evaluate internal platform skills and operating model

   Identify who will run the platform after go-live: patching, upgrades, backups, monitoring, and incident response. Keycloak runs on Java and its realm export and import process has limitations as a backup mechanism, with all nodes stopped during the operation, so plan a separate backup approach. ZITADEL self-hosts with Docker Compose or Kubernetes on PostgreSQL 14 or later. authentik requires its own container stack and database. Score each candidate against the skills your team already has and the platforms you already operate. Done means a named owner for each operational task and a skills gap list that either your team or an implementation partner will cover.

6. Run a pilot with a representative application set

   Build a test environment in your own infrastructure and connect a representative set of applications, including at least one SAML app, one OIDC app, one LDAP-dependent app and one application with SCIM provisioning if you use it. Test MFA enrollment, group-based access, and login flows for each candidate. Document where each platform needs custom configuration or cannot meet a requirement. Confirm the pilot results with the application owners. Done means a signed pilot report that records pass or fail for every test case and a single recommended candidate, or a decision to split the estate across platforms.

7. Record the decision and the exit criteria

   Write the selected platform, the rejected options and the reasons into a decision record. Include the criteria that would trigger a re-evaluation, such as a change in license terms, a missing protocol required by a new application, or a support gap. Store the record with the architecture documentation so that auditors and future owners can see why the choice was made. Done means an approved decision record that lists owners, the review date and the migration prerequisites, such as the user export approach from Okta covered in the migration section of this page.