Authentik → Okta
Authentik ↔ Okta: integration to migration path.
SSO is load-bearing — break it and everyone is locked out of everything at once, so we never flip a switch. Authentik goes live behind Okta first, federating to it as an upstream Source, your applications move one at a time against a parallel trust, and only then is Okta peeled away in layers. No outage, no cutover day, no forced 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 topology that makes this zero-outage is identity brokering: Authentik registers Okta as an upstream OAuth2/OIDC Source, 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 Authentik, with Property Mappings replicating the exact claim contract each app already trusts. Once every app trusts Authentik, we move the password source of truth — cleanly via an LDAP Source if AD sits behind Okta — then MFA, then switch Okta off. Each layer is independent and reversible. You are never betting the company on one big cutover.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We classify every app by protocol (SAML / OIDC / WS-Fed / password-vaulted), NameID format, SCIM consumer flag, group-to-role mapping, MFA factor mix, and where passwords actually live — Okta cloud directory or a delegated AD. Read-only against the Okta API. Nothing changes.
Authentik goes live behind Okta
Authentik stands up in HA and registers Okta as an upstream OAuth2/OIDC Source. A canary population authenticates through Authentik against Okta, with an enrollment Flow linking existing users by verified email. No production app trusts Authentik yet.
New apps land on Authentik
Every net-new app integrates as an Authentik Provider and Application, with Property Mappings shaping an Okta-equivalent claim contract. Authentication still resolves at Okta upstream; your existing apps are untouched.
Existing apps move, one at a time
Each app is pointed at Authentik 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, and Property Mappings replicate the app's existing attribute statement.
Source of truth moves to Authentik
Authentik begins validating credentials directly. If an AD or LDAP store sits behind Okta — the common enterprise case — an LDAP Source binds straight to it, with no password migration at all. If Okta's own cloud directory is the master, we scope an on-login hash-capture approach during inventory, which depends on Okta permitting Direct Grant.
MFA moves; Okta becomes downstream
Authentik takes over MFA via its Authenticator Stages (WebAuthn / passkeys preferred, TOTP fallback), enrolled on each user's natural next login — staggered, never a flag day. Okta flips to a downstream SAML consumer for its own residual tenant apps.
Retire Okta
Residual Okta logins are admin-only. We repoint SCIM consumers to Authentik in waves, cut the tenant trusts, and hold the Okta tenant read-only for a 30-day evidence window before cancelling the contract.
Feature parity
Where Authentik matches Okta, and where it doesn't.
| Capability | Authentik | Okta | Parity |
|---|---|---|---|
| OIDC / OAuth IdP | Authentik OAuth2 / OpenID Provider plus Application | Okta OIDC app plus Authorization Server | At parity |
| SAML 2.0 IdP | Authentik SAML Provider plus Property Mappings | Okta SAML app plus attribute statements | At parity |
| SCIM provisioning | Authentik SCIM Provider (client); server-side endpoints version-dependent | Okta SCIM client plus Lifecycle Management | Partial |
| Authn flows / policies | Flows plus ordered Stages plus expression-evaluated Policy Bindings | Okta Authentication / Sign-On Policies | At parity |
| MFA / passkeys | Authenticator WebAuthn / TOTP Stages | Okta Verify, WebAuthn, TOTP | Partial |
| Identity brokering / federation | Sources (OAuth2 / OIDC, SAML, LDAP, Kerberos, Plex) | Okta Inbound Federation plus social IdPs | At parity |
| LDAP / AD integration | LDAP Source (bind-and-validate, no shadow copy) plus LDAP Provider | Okta AD Agent into a Universal Directory shadow copy | At parity |
| User directory | Authentik user store plus groups | Okta Universal Directory (multi-source mastering) | Partial |
| Admin API | Authentik REST API (/api/v3/...) | Okta Management API | At parity |
| Risk / threat detection | None native (bolt on WAF / HIBP via expression Stage) | Okta ThreatInsight | SaaS only |
| Lifecycle / workflows | Event listeners plus webhooks plus HRIS pipeline | Okta Workflows | SaaS only |
| Cost model | Self-hosted compute plus ops; Enterprise tier optional | Per-MAU (Workforce plus Customer Identity SKUs) | Partial |
| Compliance (SOC 2 / FedRAMP / ISO) | You operate and evidence the boundary | Vendor-operated, vendor-attested boundary | SaaS only |
What we're honest about
The caveats most vendors leave out.
MFA factors re-enroll once
TOTP secrets and WebAuthn credentials are bound to the provider that issued them — they cannot be exported from Okta, and no API on either side exports the seed. Every user re-enrols a factor exactly once, on their natural next login, staggered over weeks. It is never a flag-day reset, and passkeys usually end up a better factor than what they replace.
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. Authentik ships no first-party mobile push authenticator. We tell you where that is a real change for your users rather than pretend it isn't.
ThreatInsight and Workflows are SaaS-only
Okta ThreatInsight relies on cross-customer IP-reputation telemetry no self-hosted tool can reproduce; replace it with your WAF, Cloudflare Bot Management, or internal anomaly signal injected into an Authentik expression Stage. Okta Workflows lifecycle automation re-homes into an HRIS pipeline or Authentik event listeners — a real workstream, not a checkbox.
The iss / sub change is the cutover risk
OIDC sub is opaque and per-issuer; the issuer changes from your Okta org to the Authentik host, so apps keying records on sub rather than verified email can create duplicates at cutover. We audit every consumer for sub-pinning in Phase 0 and, for high-value apps, emit the old Okta sub as a custom claim so the app can match. It is the number-one cause of 'I lost my data' tickets, so we surface it 30 days ahead.
Self-hosting means you own uptime
Once Okta is gone, Authentik being down means logins are down — there is no managed-service backstop, and no vendor 99.99% SLA or 24×7 SOC on your IAM control plane. That is exactly why we run it: HA across server and worker pods, multi-AZ Postgres and Redis, break-glass admin in your vault, and a tested DR runbook with a recovery-time target. Managed, not just installed.
Why this beats a flag day
Reversible per app, soaked before you cancel.
Every per-app move rolls back in under 15 minutes while the parallel Okta trust is left live, so a bad cutover is a single toggle, not an incident. And we never cancel the Okta contract on a hunch: each app soaks at full traffic with a login error rate that meets or beats the Okta baseline, and the tenant holds a read-only evidence window of at least 30 days before the licence is terminated. You are never betting the company on one big cutover.
See whether your stack migrates cleanly.
A call with a senior identity engineer. We map your apps by protocol, flag the password-vaulted ones that can't move and the iss/sub-pinned ones that need care, and tell you honestly what the path off Okta looks like for your environment — before you commit to anything.
Map my migration →