Okta vs Keycloak: which fits your workforce identity needs
Your decision usually starts with a renewal notice, a per-user price change, a data residency rule or a concern about lock-in on Okta Workforce Identity. Okta fits teams that want a managed cloud service with vendor-run operations. Keycloak fits teams that need identity data inside their own infrastructure and can carry the operations and security patching themselves. Neither answer is right in general, so the choice should follow from a few concrete facts about your organization.
Start with who will operate the service. Okta runs the platform, its upgrades and its availability. With Keycloak, your team or your implementation partner owns the database, the high availability design, the backups and every release. Keycloak is licensed under Apache 2.0 and its project plans four minor releases a year, so the upgrade workload is recurring rather than occasional. Next, map where identity data must live. If a regulator or internal policy requires directory data, logs and admin access to stay in your own data centers or cloud accounts, a self-hosted deployment is the direct route. Confirm with Okta in writing where its tenant, sub-processors and support access sit before assuming a gap.
Then list every protocol, directory and application that must connect. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it federates existing LDAP and Active Directory servers. Check each Okta integration you rely on, including the AD agent, SCIM provisioning and any proxy or privileged access add-ons, because those need a named replacement. Finally, confirm the people available. Ask whether you have staff who can run PostgreSQL or another supported database, test minor releases before rollout and handle MFA re-enrollment at scale. If that capacity is missing, get a fixed-scope quote for operations and support before you commit to a migration date.
Which option fits which scenario
This table maps common organizational situations to the option that tends to fit them better, with the condition that makes each answer hold. Use it as a starting point for your own requirements review, not as a final decision, and confirm each row against your identity architecture, contracts and regulatory obligations.
| Scenario | Better fit | Condition that makes this hold |
|---|---|---|
| Cloud-first SaaS estate with no on-premises directory | Okta Workforce Identity | Most applications support SAML or OIDC natively, there is no domain controller to federate, and the team has no appetite to run identity infrastructure or patch it. |
| Identity data must stay in your own data center | Keycloak | Your policy requires user records, credentials and authentication logs to remain on infrastructure you control, and you can staff patching, backup and high availability. |
| Active Directory or LDAP as the system of record | Keycloak | Accounts are authoritative in AD or LDAP and Keycloak can federate to them, so you keep the directory and add SSO on top rather than rebuilding user stores. |
| Team with no platform engineers | Okta Workforce Identity | No one on staff can own database operations, clustering, upgrades and security advisories, and no managed partner is contracted to carry them. |
| Team with a dedicated platform or identity engineering group | Keycloak | Engineers can own the Keycloak deployment, the upgrade cadence and the monitoring, and the organization accepts that these tasks move from the vendor to its own staff. |
| Regulated environment that needs its own authorization boundary | Keycloak | The assessor expects identity components inside your boundary, and you can produce the control evidence yourself or with an independent assessor. Confirm the requirement with your assessor before deciding. |
| Heavy reliance on Okta-managed integrations and lifecycle workflows | Okta Workforce Identity | Many provisioning connectors and workflow automations already run in Okta, and rebuilding them on Keycloak would be a large project for your team. |
| Mixed estate with legacy header or Kerberos apps | Depends on the rest of the stack | Access to legacy apps is handled by a separate gateway or proxy, so confirm how each option covers those apps before choosing an identity provider. |
Where identity data lives and who controls it
Okta Workforce Identity runs as a cloud service operated by Okta. Your tenant's directory, policies, application configuration and authentication events are processed in Okta-operated infrastructure, in the regional environment assigned to your organization. You do not choose the hardware, the database or the patching schedule, and your visibility into how the service runs comes from Okta's contract terms, reports and support processes.
- Data location: Identity records and configuration sit in the regional cell Okta assigns to your tenant. Ask Okta in writing which region holds your tenant and under what conditions that assignment can change.
- Log location: System logs and authentication events are retained within Okta's service. Confirm the retention period and the export method you would use to send them to your own SIEM.
- Support access: Okta staff and sub-processors may access tenant data under Okta's support processes. Confirm the scope of that access, the approval model and the current sub-processor list.
- Backups: Okta operates backup and recovery for the service. Ask which recovery commitments appear in the contract and which restore actions, if any, you can perform yourself.
- Compliance: Your assessments can rely on Okta's assurance reports only for the controls those reports cover. Map each control your auditor asks about to Okta's report or to your own evidence.
Confirm the Okta data location terms, sub-processor list and log retention in your contract before comparing them with a self-hosted option.
Keycloak runs as software inside an environment you choose: your cloud account, a private data center or a hosted environment you control. Identity records, credentials, sessions and logs stay wherever your team deploys the database and the nodes. Your organization owns those controls, so data location becomes a design decision that you document and can show an assessor.
- Data location: Realm data lives in the database you configure. Keycloak supports production databases including PostgreSQL 14 to 18, so the database region, network placement and encryption are settings your team controls.
- Log location: Logs go to the destinations your team configures, such as a central log platform. Metrics can be exposed to your own monitoring stack.
- Support access: Only the people and vendors you grant access can reach the servers. Any outside support, including DeployOpen, works under access terms you approve in writing.
- Backups: Back up the database with your database tooling on a schedule you set and test restores regularly. Realm export and import with
kc.shhas documented limitations and requires all nodes to be stopped during the operation, so use it as a supplement to database backups. - Compliance: The software does not carry an audit report for your deployment. Your controls, logs and evidence are produced by your team, and an independent auditor issues any report. DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.
Check the database version, restore test results and log destinations against your data residency policy before go-live.
On an isolated network, Keycloak can run without internet access, which a cloud identity service cannot offer. Identity data, logs and update packages move only through transfer processes your security team defines. The design keeps every dependency inside the boundary, including the database, the container or package sources, the time source and the monitoring stack.
- Data location: All identity records stay on hosts inside the isolated enclave. Choose a database such as PostgreSQL 14 to 18 that your team can operate and back up inside the boundary.
- Log location: Forward logs to a collector inside the enclave only. Document how any log extract leaves the enclave for review and who approves it.
- Support access: Remote vendor access is usually not available on isolated networks. Plan for on-site work or approved, recorded remote sessions.
- Backups: Store backups inside the enclave or move them with approved media. Test restoration on a separate isolated host so that recovery steps are proven before an incident.
- Patching: Security updates arrive through controlled transfer of approved packages. Track each transfer as a change record, since it becomes part of the patch evidence.
Access logs, change records and transfer records are the evidence an assessor will ask for first. DeployOpen prepares those controls and evidence, but independent auditors issue any report.
Confirm the transfer and approval process with your security team before you define the enclave boundary.
Who carries operations and security patching on Keycloak
With Okta, the vendor runs and patches the cloud service. With self-hosted Keycloak, your team owns upgrades, database high availability, schema changes, operator settings and backups. The cards below list the responsibilities to staff and plan before you commit.
Release cadence and upgrade planning
Keycloak has planned four minor releases a year and a major release every two to three years since version 26.0. Breaking changes in a minor release are opt-in, which lowers surprise risk but still means someone reads each release, tests it against your realms and applies it. The current release is 26.8.1, published October 13, 2026. Assign an owner for monthly review of release notes and a patch window before go-live.
Database high availability design
Keycloak's supported high availability designs both require a synchronously replicated database. Your team must choose among a single cluster spread across availability zones, the multi-cluster v2 design, or the deprecated multi-cluster v1 design, and then operate the database replication behind it. Confirm which production database and version your environment supports, and who is paged when replication lags.
Schema migration at upgrade
Keycloak migrates its database schema automatically at startup by default. For large deployments, the upgrade guide suggests manual migration, where your database administrators apply the SQL before the new server starts. Decide which mode you will use, rehearse the upgrade on a copy of production data, and confirm that your change process allows a schema change to run outside the application deployment.
Operator update approval mode
If you run Keycloak on Kubernetes with the Keycloak Operator, the operator documentation strongly recommends manual approval mode for operator updates. Automatic updates can move a cluster to a new version without a review step. Keep manual approval on, and make the approval part of the same change control that covers Keycloak releases, so that no version reaches production unreviewed.
Realm export is not a full backup
Keycloak exports and imports realms as JSON files with the kc.sh export and kc.sh import commands. The documentation warns that this has limitations as a backup and restore method, and that all nodes must be stopped while it runs. Treat database-level backups and restore tests as your primary recovery path, and confirm with your team how a restore would be run in a real outage.
Security patching and vulnerability response
Okta patches its own cloud service. With Keycloak, your team or a support provider must watch security advisories, test fixes and deploy them to every node, the database and the operator. Ask who receives notice of new advisories, how quickly an emergency patch can reach production, and whether your support contract covers out-of-cycle fixes.
What Okta and Keycloak cost to own
Okta's cost is set by a written contract, not a public price list, so the first step is to pull your order form, the Okta Workforce Identity subscription terms and every add-on and suite line item. Okta's pricing is generally structured around a per-user subscription, product suites such as the tiers that include Adaptive MFA or API Access Management, and separate add-ons, with an annual minimum that applies regardless of headcount. Ask your account team to confirm in writing which users are billed (active, licensed or all directory users), how the annual minimum applies, what happens to the price at renewal, and whether support tiers, sandbox tenants and extra integrations are included. Those terms, not list rates, decide your recurring cost.
Keycloak carries no license fee because it is licensed under the Apache License 2.0, so the software cost is zero. The recurring costs are the infrastructure to run it, a supported production database from the list in the database guide, enough nodes for high availability with a synchronously replicated database, monitoring, backups, and staff time for patching and upgrades. Staff time is usually the largest line. A vendor support subscription, such as the Red Hat build of Keycloak, is optional but is a common one-time planning item if your policy requires a supported distribution. Costs rise with user count, the number of environments you keep, the number of integrations, and the number of people on call. Before requesting a quote from any vendor or partner, ask for a written scope that lists each of these components and who pays for each.
What moving from Okta to Keycloak involves
The sequence turns Okta's users, apps and policies into a Keycloak realm that your team can test, cut over and then operate without Okta. Each step ends with an output you can check before moving on.
Inventory applications, policies and groups
Your identity or application owner lists every app connected to Okta, including its protocol (OIDC, SAML, WS-Federation or header-based), its owner, its group assignments and the Okta policies that apply to it, such as sign-on, password and MFA rules. Okta's Admin Console and API expose this data, and the sibling page on exporting from Okta covers which items can be exported and which must be rebuilt by hand. The output is a register that maps each application to a target Keycloak client and an owner who will test it.
Export the active user list
Okta documents three ways to export 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. Use the API filter if you need repeatable exports with attributes that the report omits, and store the file under your own access controls because it contains personal data. The output is a validated user file with usernames, emails, departments and group memberships, checked against a count from Okta's console.
Decide where identities live
Decide whether Keycloak's own user store will hold identities or whether an LDAP directory or Active Directory will remain the source of truth and be federated into Keycloak. If Active Directory already holds users, Keycloak's built-in user federation with LDAP or Active Directory replaces the Okta AD agent pattern and keeps passwords in one place. The output is a written decision on the user store, the attribute mapping and which team owns account creation, changes and removal.
Rebuild clients, flows and policies in Keycloak
Recreate each application as a Keycloak client, configure redirect URIs, client scopes, role or group mappings and token claims, and rebuild the authentication flows and required actions that replace Okta's sign-on and MFA policies. Realm exports with the kc.sh export and kc.sh import commands can move realm structure between environments, but the Keycloak docs describe limitations as a backup and restore mechanism and require all nodes to be stopped during the process, so treat exports as a way to copy configuration, not as a complete migration. The output is a configuration in version control, reviewed by the application owners and deployed to a non-production realm.
Plan password and MFA re-enrollment
Users cannot move Okta's stored credentials into Keycloak in a standard export, so decide between forced password reset at first login, federation to a directory that keeps existing passwords, and a staged re-enrollment window. Plan MFA re-enrollment for each factor Okta holds, including hardware keys, and communicate the steps to users before cutover. The output is a signed-off re-enrollment plan with a help desk script and an escalation path for users who cannot enroll.
Run parallel testing with pilot users
Run Keycloak alongside Okta for a pilot group, with each application owner signing in through both paths and checking attributes, group-based access, logout and session behavior. Test failure paths too, such as a locked account, an expired password and a lost MFA device, and confirm the Keycloak database, high availability design and monitoring behave as planned. The output is a test record with pass or fail results for each application and a list of defects that must close before cutover.
Cut over applications in controlled waves
Move applications to Keycloak in groups, starting with lower-risk apps, and keep the Okta configuration intact so you can point an application back if a fault appears. Monitor sign-in success, error rates and help desk volume after each wave, and record the rollback decision criteria before the first wave starts. The output is a cutover log showing which applications run on Keycloak, the date each moved and the evidence that its users can sign in.
Retire Okta and keep Keycloak operated
After every application is confirmed on Keycloak, disable Okta sign-on, remove the AD agent and revoke Okta API tokens, then close or downgrade the Okta subscription according to the contract terms your procurement team has agreed. From this point your team owns Keycloak patching, backups, upgrades and monitoring, and Keycloak's release schedule and opt-in breaking change policy should be built into that routine. The output is a decommissioning record and a documented operations runbook with named owners.
Questions buyers ask before switching from Okta
How much effort does switching from Okta to Keycloak take?
The effort depends mostly on how many applications, user stores and MFA policies sit behind Okta today. Each SAML or OIDC application needs its client rebuilt in Keycloak and tested, and each Okta policy needs an equivalent authentication flow. Directory work is the next driver: if Okta reads users from Active Directory through the Okta AD agent, that link must be replaced with Keycloak's LDAP or Active Directory user federation. Data movement is usually the smallest part, since user lists can be exported from Okta, but app and policy configuration has to be rebuilt by hand. Ask any provider to break the estimate down by application count, directory sources, MFA factors and cutover approach before agreeing a scope.
Can our own team migrate from Okta without outside help?
A capable identity or platform team can run a Keycloak migration in-house, provided it has time, a test environment and someone who owns the cutover. The work involves standing up Keycloak with a supported production database, configuring realms, clients and federation, and testing every application before users move. Teams without prior Keycloak experience often bring in outside help for design, hardening and the cutover window, then operate the platform themselves. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, so you can choose full delegation, shared work or review only.
How long does an Okta to Keycloak migration take?
The duration depends on scope and must be agreed in writing before work starts. The main variables are the number of applications, the complexity of their SAML and OIDC configuration, the directory sources to federate, the number of users who must re-enroll MFA, and whether the project runs in parallel with Okta or replaces it in one cutover. Compliance evidence requirements and change windows also extend the schedule. Ask for a plan with phases, acceptance tests for each application and a clear point where Okta is switched off, rather than a single headline number.
What skills does a team need to run Keycloak in production?
Operating Keycloak requires people comfortable with Linux, containers or Kubernetes, a supported relational database such as PostgreSQL, TLS and reverse proxy configuration, and identity protocols including OpenID Connect, OAuth 2.0 and SAML 2.0. Staff also need to understand realms, clients, client scopes and user federation, plus how high availability depends on a synchronously replicated database. Monitoring, backup and restore planning, and upgrade testing are ongoing duties. Organizations without this depth usually retain a support subscription or a managed operations partner. Confirm your staffing against the number of people who must be able to troubleshoot a failed login at 2 a.m.
Who patches Keycloak once we run it ourselves?
Your organization owns patching for a self-hosted Keycloak, while Okta's cloud service is patched by Okta. You must track Keycloak releases, test each update against your applications and federation, and deploy it to production. The project plans four minor releases a year and says breaking changes in a minor release will be opt-in, which makes regular upgrades more predictable. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates so upgrades do not happen unexpectedly. Database schema migration runs automatically at startup by default, and large deployments may prefer applying the SQL manually. Agree on who watches security advisories, who approves changes and how fast critical fixes are applied.
Can Keycloak fully replace Okta MFA and Adaptive MFA?
Keycloak covers standard factors such as one-time passwords and WebAuthn, which makes it a workable replacement for basic MFA on many applications. Okta Adaptive MFA adds risk-based decisions using signals such as device context, network location, behavior and threat data, and open source does not replicate that set of signals out of the box. Push notification apps, managed device checks and vendor-specific enrollment flows also need separate planning. For RADIUS, Windows logon and hardware tokens, a companion product such as privacyIDEA is often added. Before deciding, list the factors each application requires and the risk rules you rely on today, then confirm coverage against your own test cases.
What changes for users when passwords and MFA are re-enrolled?
Users typically see a new login page, a new sign-in address and a request to set up MFA again, because factor secrets generally cannot be moved safely from Okta. Password hashes are the first constraint: whether they can be exported depends on what Okta provides for your tenant, so confirm this in writing before planning. Where hashes are unavailable, users set a new password at first login, which adds a support load around the cutover. Plan a communication schedule, self-service enrollment instructions, a fallback path for users who lose their device, and a window where both systems remain available for testing.
When staying with Okta makes more sense
Staying with Okta is the better choice when the organization wants identity operated by a vendor, has little platform engineering capacity, or depends on Okta-specific products. The clearest case is a team that cannot staff a highly available Keycloak cluster with a synchronously replicated database, regular upgrades and patching, and tested backups. Keycloak's own backup guidance describes realm export and import as having limitations, and the import and export process requires all nodes to be stopped. If no one on the team can own those runbooks and run them under pressure, a cloud service that Okta operates may carry less risk, even though the license cost is higher. Ask Okta to confirm which tenant, availability and support commitments are written into the contract, and compare them with the operating hours and on-call coverage your own team can actually provide.
A second case is dependence on Okta-specific integrations and governance products. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 and can federate existing LDAP and Active Directory servers, but a catalog of pre-built application integrations, Okta Workflows, Access Gateway, Identity Governance or Adaptive MFA may not have a direct equivalent. Inventory every app, workflow and policy that Okta enforces today, then mark each one as portable, rebuildable or not replaceable. If a large share of the estate sits in the last category, that is a strong reason to keep Okta for those functions, or to keep it entirely. Also check the contract, including any minimum commitment, renewal date and exit terms, since a contract the organization values may outweigh a lower software price.
Before deciding, put the conditions in a written scope and run a pilot. The scope should name the applications in the pilot, the factors to be tested (for example, SAML and OIDC sign-in, LDAP or Active Directory federation, MFA enrollment, and provisioning), the staffing model, and the criteria that would end the trial. Run the pilot against a non-production realm or instance, with real application owners signing in, and measure how long the platform team takes to complete upgrades and restores. The result is a documented choice, either to stay with Okta for defined scope or to proceed to a migration plan, and both outcomes are better than a decision made on license price alone. Independent reviewers and your own risk function should sign off on the decision record.
How DeployOpen helps evaluate and move from Okta to Keycloak
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Okta vs Keycloak, we start with a written scope that tests your app inventory, directory and MFA needs against what Keycloak covers, then build and hand over only what that scope agrees.
How we scope
- We inventory SAML and OIDC applications, group assignments, policies and MFA factors exported from your Okta tenant.
- We map each Okta capability to a Keycloak feature, marking gaps such as risk-based signals for separate review.
- We agree deliverables, timelines and exclusions in writing before any work starts, since engagements are fixed-scope.
How we build
- We deploy Keycloak in your own cloud accounts, data centers or air-gapped network, with the database and high availability design you choose.
- We configure realms, LDAP or Active Directory federation, clients and MFA, and test re-federation of each application.
- We run security testing against the identity deployment and document the controls and evidence it produces.
How we hand over
- We deliver runbooks for backups, realm export limits, node stops during export and manual schema migration decisions.
- We document upgrade procedures, including the Operator's manual approval mode and how your team reviews minor releases.
- We train your administrators on the admin console, client onboarding and incident response for the identity service.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the migration project.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any formal reports.
- Ask for the scope, exclusions and support terms in writing so your quote reflects the work your environment needs.
