Okta → Keycloak

Migrate off Okta without a flag day.

SSO is load-bearing — break it and everyone is locked out of everything at once. So we never flip a switch. Keycloak goes live behind Okta first, your applications move one at a time against a parallel environment, and only then is Okta peeled away in layers. No outage. No cutover day. No mass re-credentialing — and every step rolls back in minutes.

The one honest exception is a single MFA re-enrollment per user, staggered on their next login — never a reset event. We say so up front, because the rest of this only matters if you can trust it.

The idea

Become the front door first. Retire Okta last.

The trick that makes this zero-outage: Keycloak federates to Okta as an upstream identity provider, so it becomes your login front door without changing a single app's credentials. Okta keeps validating passwords and MFA while apps quietly move onto Keycloak. Once every app trusts Keycloak, we move the password source of truth, then MFA, then switch Okta off — each layer independently, each reversible. You are never betting the company on one big cutover.

The phases

Seven steps. Each one reversible.

0

Inventory

We map every app by protocol (SAML / OIDC / WS-Fed / password-vaulted), every group-to-role rule, your MFA factor mix, and where passwords actually live. Read-only. Nothing changes.

Users see: No user impact.

Rollback: N/A

1

Keycloak goes live behind Okta

Keycloak stands up in your cloud (HA, multi-node) and federates to Okta as an upstream identity provider. Okta still validates every credential. A canary group proves the path before anything production trusts Keycloak.

Users see: None for production users.

Rollback: Delete Keycloak — no app trusts it yet.

2

New apps land on Keycloak

Every net-new app integrates with Keycloak from day one; authentication still resolves at Okta on the back end. Your existing apps are untouched.

Users see: None — users still sign in once at Okta.

Rollback: Per-app: revert to direct Okta.

3

Existing apps move, one at a time

Each app is pointed at Keycloak alongside its existing Okta trust, flipped to a 10% slice, watched, then ramped to 100%. Waves run low- to high-blast-radius. Okta still owns credentials throughout.

Users see: None — only the app's IdP endpoint changed.

Rollback: Flip the default IdP back. Under 15 minutes while the parallel trust is live.

4

Source of truth moves to Keycloak

Keycloak begins validating credentials directly. If AD or LDAP sits behind your Okta tenant — the common enterprise case — this is clean: Keycloak binds straight to it, with no password migration at all. If Okta's own cloud directory is the master, we scope the approach to your MFA setup during inventory; for some users that means setting a password once rather than an invisible move. We tell you which case you're in before Phase 1.

Users see: Login screen rebrands from Okta to Keycloak — one communicated change. AD-backed users: no new credentials. A cloud-directory subset may set a password once.

Rollback: Revert to redirect-to-Okta. Under 15 minutes.

5

MFA moves; Okta becomes downstream

Keycloak takes over MFA (passkeys / WebAuthn preferred, TOTP fallback), enrolled on each user's natural next login — staggered, never a flag day. Okta flips to a downstream consumer for its own residual apps.

Users see: One-time factor enrollment per user, on their next login. No mass reset event.

Rollback: Reorder the flow — Okta MFA primary again. Under 15 minutes.

6

Retire Okta

Residual Okta logins are admin-only. We repoint provisioning, cut the trusts in waves, and hold the Okta tenant read-only for 30 days as an evidence window before cancelling the contract.

Users see: None for app sign-in.

Rollback: Reactivate within the 30-day read-only window.

What we're honest about

The caveats most vendors leave out.

MFA factors re-enroll once

TOTP secrets and passkeys are bound to the provider that issued them — they cannot be exported from Okta. Every user re-enrols a factor exactly once, on their next login, staggered over weeks. It is never a flag-day reset, and we communicate it well ahead. Passkeys usually end up a better factor than what they replace.

Password-vaulted (SWA) apps don't migrate

Apps with no real SSO — the ones Okta logs into by replaying a stored password — have nothing for Keycloak to federate. They need real SSO or a dedicated password manager. We flag every one in the inventory phase, before you commit.

Okta Verify push has no exact equivalent

If you rely on Okta Verify push or FastPass, the honest replacement is passkeys, not a like-for-like push clone. We will tell you where that is a real change for your users rather than pretend it isn't.

Self-hosting means you own uptime

Once Okta is gone, Keycloak being down means logins are down — there is no managed-service backstop. That is exactly why we run it: HA across nodes and zones, a break-glass admin path, and a tested DR runbook with a recovery-time target. Managed, not just installed.

See whether your stack migrates cleanly.

A 30-minute call with a senior identity engineer. We map your apps by protocol, find the ones that need special handling (and the few that can't move), and tell you honestly what the path looks like for your environment — before you commit to anything.

Map my migration →