Okta prices per user, gates capabilities like MFA, lifecycle, and governance behind separate SKUs, and applies annual contract uplifts. Keycloak is the most common open-source destination: a mature identity provider supporting OIDC and SAML, realms, directory federation, and MFA, with no per-user fee. The protocol re-integration is routine; the parts that bite are password migration and MFA re-enrollment. Plan around those.
What you gain, and what you give up
You gain a full-featured IdP you run yourself, with no per-seat cost and no feature paywall. You give up Okta’s managed reliability and its turnkey higher-tier products, advanced lifecycle automation, identity governance, and threat-detection SKUs, which you’ll either build, add via other tools, or do without. You also own availability: Keycloak in production means an HA deployment backed by an external database (PostgreSQL) and a real upgrade plan.
The pricing case for leaving is usually the clearest part. Okta charges per user per month, and the capabilities most organisations actually rely on, MFA, lifecycle automation, and governance, are each separate SKUs that stack on top of the base seat price, then rise again at annual renewal. A larger part of the lock-in is architectural: the more you lean on Okta-specific integrations, Workflows, and its network of pre-built app connectors, the more of that convenience you rebuild yourself on the way out. Keycloak removes the per-user meter, but it moves the cost from a licence line to engineering and on-call time. The calculator above is where you weigh those against each other; treat any figure as illustrative until you have scoped the operational ownership below.
How the pieces map across
- Okta org → Keycloak realm.
- Okta applications (OIDC/SAML) → Keycloak clients, re-registered one per app.
- Universal Directory → Keycloak users, typically with LDAP/Active Directory federation (user federation) rather than a one-time copy.
- Okta groups → Keycloak groups and roles.
- Okta MFA → Keycloak OTP and WebAuthn/passkeys.
- Okta Workflows / lifecycle → SCIM provisioning plus custom automation.
The password problem (read this first)
Okta does not let you export user password hashes. That single fact shapes the whole migration. Your options come down to three:
- Just-in-time (JIT) migration. Stand up a Keycloak custom user storage / federation provider that, on a user’s first login, validates the credential against Okta’s API, then stores it natively in Keycloak. Users migrate transparently as they sign in. This is the smoothest experience and the usual recommendation.
- Forced reset. Cut over and require every user to reset their password via email. Simple to build, heavier on users and support.
- Passwordless. If you’re moving to WebAuthn/passkeys anyway, enrollment effectively replaces the password and sidesteps hash migration.
MFA enrollments don’t transfer either, users re-enroll their OTP or passkey in Keycloak regardless of the path you choose.
Bringing users and groups across
Where the identities come from decides how much work the user migration is. If Okta’s Universal Directory is itself fronting an on-prem Active Directory or LDAP, the cleanest move is to point Keycloak’s user federation at that same directory. Users and group membership flow in without a copy, and for AD-backed accounts you may not have a password-migration problem at all, since authentication delegates to the directory.
Where identities live only in Okta, you sync them out. Okta exposes users and groups through SCIM and its admin API, and Keycloak imports through its own admin API. Map Okta groups deliberately: some become Keycloak groups (membership and hierarchy) and some become roles (authorization), and apps see them only if you attach the right client scopes and protocol mappers. Decide the group-to-role split before you cut over the first app, because changing it afterwards means re-testing every app’s authorization.
Rebuilding each app as a client
Every Okta application becomes a Keycloak client, and this is the bulk of the routine work. Re-register one app at a time:
- SAML apps: create a SAML client, exchange metadata, set the entity ID and ACS URL, and load the new signing certificate. The relying party has to trust Keycloak’s certificate, so this is a coordinated change on both sides, not a one-way edit.
- OIDC apps: recreate the client, redirect URIs, and scopes, and confirm the token and userinfo claims match what the app read from Okta.
- Claim parity: an app that expected an Okta claim by a specific name needs a Keycloak protocol mapper producing the same name and value. Diff a real assertion or token from each side before you flip the app.
Keep each app pointed at Okta until its Keycloak client is proven, then move it. This is what lets you run both IdPs in parallel and cut over app by app instead of on a flag day.
A cutover sequence that holds up
- Deploy Keycloak for production: multiple instances behind a load balancer, an external PostgreSQL, and a tested upgrade/backup routine.
- Build the realm: federation from AD/LDAP (or import users via the admin API / SCIM), groups, and roles.
- Choose and build the password strategy (JIT provider, forced reset, or passwordless) before any app cuts over.
- Re-register applications as clients, recreate each OIDC client or SAML integration, exchange SAML metadata and certificates, and update redirect URIs.
- Migrate per application by user group, validating login, token claims/attributes, group-based authorization, and MFA at each step.
- Theme the login so the experience is recognizable, and wire up email for verification and reset flows.
Easy things to get wrong
- SAML cert and metadata rotation is per-app and easy to get wrong, schedule it.
- Token claim mapping: apps expecting specific Okta claims need matching Keycloak protocol mappers.
- Session/SSO behavior differs; test idle and max session lifetimes and single logout.
- HA and DB sizing are real work, a single Keycloak instance is fine for a pilot, not for production.
Before you commit
Okta → Keycloak removes per-user cost and feature paywalls in exchange for running your own IdP. The protocol work, clients, federation, claims, is routine; the make-or-break items are the password strategy (JIT migration is usually best) and MFA re-enrollment, plus a genuine HA deployment. Model your per-user savings in the calculator above, and treat them as illustrative until you’ve scoped the operational ownership you’re taking on.