Okta vs authentik: when each one fits
Choose Okta when your organization wants a managed suite and a vendor that carries the operations, patching and uptime of the identity platform. Choose authentik when a renewal, a per-user cost review, a data residency requirement or a wish for fewer cloud dependencies pushes you toward self-hosted SSO, and your team is ready to run it. authentik's open-source core is MIT licensed and covers OIDC, SAML, LDAP, RADIUS, SCIM and proxy authentication in the free edition, which makes it a practical fit for organizations whose identity needs centre on those protocols rather than a broad app catalog. Okta's cloud model also means identity data and authentication traffic run through its service, which matters if residency rules apply.
The decision turns on four questions. First, list every application and the protocol it needs, including legacy apps that rely on LDAP binds, RADIUS for network access or header-based access through a proxy. Second, decide whether you need the Google Workspace or Microsoft Entra ID integrations, because those sit in the paid Enterprise edition, which the authentik pricing page lists per user with a separate external user charge. Mapping those integrations to your current Okta apps tells you whether the free edition is enough. Third, identify who operates the platform. authentik's architecture uses a server container, a worker container and PostgreSQL, so you need staff to patch, back up and upgrade it, and to confirm the supported versions in the authentik security policy before choosing a release line.
Fourth, settle where identity data must live and who can reach it. Self-hosting places user records, logs and authentication data inside your own cloud accounts or data centers, but your team then owns availability and access controls. Ask your vendor and your own environment team to confirm the high availability design, backup procedure and any log retention commitments before you sign. Where the answer is mixed, for example a managed suite for some apps and self-hosted SSO for others, document which identity sources and protocols stay in each system so audits and migrations stay manageable.
Which option fits which scenario
This table matches common Okta versus authentik scenarios to the option that usually fits better, along with the condition that tips the decision. Use it to shortlist, then confirm each Okta feature your environment depends on with Okta before you rely on a gap.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small team needs SSO plus LDAP and RADIUS in one product | authentik | One self-managed service covers OIDC, SAML, LDAP, RADIUS and proxy providers in the free edition, and the team can run PostgreSQL. |
| Organization needs Entra ID or Google Workspace connectors | Okta, or authentik Enterprise | These connectors sit in authentik's Enterprise edition, so confirm the per-user cost and whether your Okta suite already covers the same connectors. |
| No platform engineers to run a database-backed service | Okta | authentik needs its server, worker and PostgreSQL run, backed up and patched by your team, while Okta operates the service in its cloud. |
| Data residency mandate requiring identity data on your own servers | authentik | Self-hosting in your own or EU-based infrastructure keeps directory data under your control, provided you confirm where Okta processes data for your tenant. |
| Broad suite need covering lifecycle, governance and access requests | Okta, or a separate governance product | authentik focuses on authentication and provisioning, so confirm which Okta governance and lifecycle features you need and whether a product such as midPoint would cover them. |
| Free community support is acceptable for production | authentik Open Source | The free edition offers community support only, so a team that needs ticketed vendor support should compare the Enterprise tier. |
| Privileged access management is needed with SSO | Okta or authentik Enterprise | authentik lists privileged access management as an Enterprise feature, so confirm the depth needed against Okta's add-on products. |
| Strict FIPS compliance or SLAs required | Okta, or authentik Enterprise Plus | authentik lists FIPS compliance and SLAs in Enterprise Plus, so confirm the exact standard and service levels you need with each vendor. |
Where the free authentik edition stops
The authentik open-source core covers most of the protocol and directory work a smaller team needs for SSO. The Enterprise directory adds the integrations, controls and support that many Okta customers rely on today, so the gap should be mapped feature by feature before any renewal decision.
Free core protocols and directories
The MIT-licensed core supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication. This covers most Okta application integrations and the LDAP or RADIUS needs that Okta often serves through its agent and add-ons. Check each Okta app against the authentik provider types, since some SaaS connectors need custom mapping.
Enterprise directory integrations
Google Workspace and Microsoft Entra ID integrations sit in the Enterprise edition, not the free core. If your Okta tenant syncs users from Entra ID or Google Workspace today, plan for that connector to be licensed or rebuilt with SCIM and LDAP. Ask authentik which connectors your deployment needs before you assume they are covered.
Per-user Enterprise pricing
The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Count your internal workforce and any external users separately, because external users drive a second line of cost. Ask for the quote in writing, including whether the annual billing minimum applies.
Enterprise Plus and support
Enterprise Plus starts at $20k annually and adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance. Free and Enterprise tiers rely on community Discord or ticket-based support, so an outage response may depend on your own staff. Decide who on your team will handle incidents before choosing a tier.
Privileged access and audit controls
Privileged access management, password history, enhanced audit logging and mTLS client certificate authentication are Enterprise features. Each one maps to a control your auditors may ask about, such as privileged account oversight or audit trail completeness. Confirm which of these you need for evidence before you assume the free core provides it.
License boundary in your deployment
The enterprise directory sits under a separate authentik EE License, while the rest of the repository is MIT. Your deployment may pull enterprise files even when you run no paid features, so review which directories your build and container images include. Ask your legal team and authentik to confirm the boundary in writing for your version.
Capability comparison from the supplied facts
This table compares Okta Workforce Identity with authentik across protocols, directory and SaaS connectors, privileged access, MFA, licensing, hosting and support. Cells marked as Enterprise features or items to confirm show where the free authentik edition stops and where Okta's current coverage needs checking against your contract.
| Capability | Okta Workforce Identity | authentik |
|---|---|---|
| OIDC, OAuth 2.0 and SAML | Core SSO protocols in the Okta suite. Confirm the exact app integration types in your tenant. | OIDC and SAML providers are included in the free Open Source edition, under the MIT-licensed core. |
| LDAP, RADIUS and proxy | LDAP and RADIUS coverage depends on the Okta products you license. Confirm with Okta before assuming parity. | LDAP, RADIUS and proxy providers are in the free edition. Proxy authentication covers header-based legacy apps. |
| SCIM provisioning | Provisioning to and from connected apps is part of the lifecycle suite. Confirm which apps your contract covers. | SCIM provider is in the free edition. Confirm the connector list for each downstream app you need. |
| Directory integration | Okta Universal Directory is the cloud user store, with the Okta AD agent for on-premises directories. Confirm agent requirements with Okta. | Connects to LDAP directories in the free edition. Confirm how your Active Directory layout maps to authentik sources. |
| Google Workspace and Entra ID connectors | Available as part of the Okta suite. Confirm current connector coverage and licensing in your contract. | Enterprise feature. Requires a paid authentik Enterprise subscription, billed per user. |
| Privileged access | Offered as the Okta Privileged Access add-on. Confirm whether it is in your current contract. | Privileged access management is an Enterprise feature. Confirm the scope against your access control requirements. |
| MFA and mTLS | MFA is part of the Okta suite, with adaptive policies in higher tiers. Confirm factor and policy coverage with Okta. | MFA is available in the free edition. mTLS client certificate authentication is an Enterprise feature. |
| Licensing model | Per-user suites with add-on products and an annual contract minimum. Confirm the current price list through a written quote. | Open Source edition is free under MIT for the core, with a separate authentik EE License for the enterprise directory. Enterprise is priced per user, plus a per-external-user fee. |
| Hosting model | Cloud service operated by Okta. Data location and sub-processors depend on the cell and contract. | Self-hosted in your own infrastructure with Docker Compose or Kubernetes, backed by PostgreSQL. Your team or DeployOpen operates it. |
| Support tiers | Vendor support is included with the suite. Confirm the support level in your contract. | Community Discord only in the free edition. Ticket-based support for subscriptions over $1k per the authentik pricing page, with dedicated SLAs and FIPS compliance in Enterprise Plus. |
| Upgrade cadence and security fixes | Okta operates the service and applies updates as the vendor. Confirm maintenance windows and release notes. | Versions are named by year and month. The 2026.5.x and 2026.8.x lines receive security fixes, with security releases announced at least 24 hours ahead. You own the upgrade. |
How authentik runs: one database and no Redis
A authentik deployment has three moving parts: a server container that runs the core application with an embedded outpost, a worker container that handles background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. According to the architecture documentation, PostgreSQL is the single stateful component you must back up, restore and size. Since release 2025.10, Redis is gone entirely. Caching, background tasks, sessions and WebSocket functions moved into PostgreSQL, so the database now carries load that used to be split across two services. Before you approve a design, confirm with your DBA how the database will be provisioned, monitored and failed over, because the database is now the critical path for login.
The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading. Treat that as a capacity check, not a footnote: review your connection limits and any connection pooler settings in a staging environment that mirrors production before you upgrade a live instance. Docker Compose is the documented starting point for test setups and small-scale production, and the Docker Compose guide states at least 2 CPU cores and 2 GB of RAM as the baseline host. That baseline describes a minimum to start from, not a sizing answer for your user base, number of applications or login peaks. For larger high-availability designs, the authentik Kubernetes installation guide is the path to evaluate, and it should be paired with a managed or highly available PostgreSQL service.
Size and load test with your own traffic. Measure logins per minute at your peak, token and refresh volume from SAML and OIDC applications, LDAP or RADIUS bind rates, and outpost traffic for proxy-protected apps, then watch PostgreSQL connection counts, CPU and query latency during those runs. Ask your authentik partner or the vendor to confirm the supported PostgreSQL versions for the release you plan to run, and keep the backup and restore procedure for PostgreSQL tested alongside the application containers. The security policy lists which release lines receive fixes, so schedule upgrades within those lines rather than letting the instance drift.
What hosting control changes for data, logs and compliance
Where identity records live, who can read logs, who can reach the system for support, and who patches it all decide how much evidence your team must produce itself. Each card below is a question to settle before choosing between Okta and a self-hosted authentik deployment.
Data location of identity records
With authentik, user accounts, groups, flows, policies and audit data sit in PostgreSQL that you deploy in your own network, apart from uploaded files. Okta stores tenant data in its cloud service, so residency depends on the cell and sub-processor arrangements in its contract. Ask Okta in writing which region hosts your tenant and which sub-processors may process identity data.
Log retention and access
Under a self-hosted deployment, authentik's enhanced audit logging is an Enterprise feature, so confirm what the free edition records and where it is shipped. Retention is whatever your team configures in PostgreSQL and your log platform. With Okta, log retention and export depend on the subscription and the System Log API, so confirm the retention period and export options for your plan.
Vendor support access
Okta staff and sub-processors can reach your tenant under its support processes, and you should confirm the conditions, approval steps and logging of that access. With authentik, the free edition gets community support only, while Enterprise adds ticket-based support for subscriptions over $1k. Either way, decide who may open a support session, and record each time a vendor or partner touches production.
Patching and security release ownership
With Okta, the vendor operates and patches the service, and you manage configuration and app integrations. With authentik, your team or DeployOpen applies releases. The security policy lists the supported versions that receive fixes and says security releases are announced at least 24 hours in advance, so set a patch window and a named owner for each upgrade.
Compliance evidence you produce
Self-hosting moves control evidence into your hands: configuration exports, access reviews, change records, backup restore tests and patch logs. DeployOpen prepares these controls and evidence for assessments, but independent auditors issue reports and certifications, and neither Okta nor authentik is certified by this page. Ask Okta which reports it provides for your tenant, and map each self-hosted control to the framework your auditor uses.
Backup and restore responsibility
In authentik, PostgreSQL holds nearly all configuration and data, so your backup, point-in-time recovery and restore testing cover identity itself, not just a database. Okta's recovery is a vendor responsibility, but you still need an exit copy of configuration. Test a restore in a separate environment and document the recovery time you can actually meet.
Cost of ownership by component
Start by separating what you pay Okta from what you pay for your own authentik deployment. On the Okta side, the cost is a per-user subscription for the suite you hold, plus any add-ons such as Access Gateway, Advanced Server Access or Workflows. Ask Okta for a written quote that lists each SKU, the user count it covers, the annual minimum and the renewal uplift, and confirm which external or partner users are billed separately. On the authentik side, the Open Source edition has no license fee, so the recurring costs are infrastructure, database operations, backups, monitoring, staff time and any support you choose to buy. The authentik pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Those are the only authentik prices to use in a comparison, and both are per-subscription figures you should confirm with authentik before budgeting.
Split the costs into one-time and recurring items. One-time costs include the design of flows, providers and groups, migrating users and policies, re-federating each SAML and OIDC application, rebuilding RADIUS and LDAP bindings, testing, and any implementation partner fees. Recurring costs include the server and worker containers, the PostgreSQL instance and its high availability setup, storage and backups, upgrade effort, security patching and on-call coverage. Authentik's 2025.10 release notes say PostgreSQL now also carries caching, tasks and sessions, and warn of roughly 50% more PostgreSQL connections after an upgrade, so budget database capacity and the people who tune it as a recurring line. The Docker Compose guide positions Compose for test setups and small production, so a production high availability design usually moves cost into the platform team's hours and hosting.
Four drivers move the totals most. User count and external user count set the Okta bill and the authentik Enterprise bill, if you need the paid features. The number of applications and protocols determines migration effort and how many provider types you must test. Whether you need Google Workspace or Entra ID integration, privileged access management or ticket-based support decides whether the Enterprise tier is needed at all. Internal skills decide whether you buy support or hire it. Ask each vendor for a quote built on the same user counts, the same applications and the same support level, and ask what happens to the price if you add external users in year two.
What a move from Okta to authentik involves
The sequence moves users, applications and access policies from Okta to authentik in stages, so each app is proven on the new provider before Okta is switched off. The result is a documented cutover with a known list of what was rebuilt, what was re-enrolled and what still depends on Okta.
Inventory apps, policies and groups
Your identity or platform team lists every Okta application integration, its protocol (OIDC, SAML, SWA or header-based), the group assignments behind it, and every sign-on and password policy that applies. Include LDAP, RADIUS and Okta AD agent dependencies, since those clients need a separate path. The step is done when each app has an owner, a protocol and a target authentik provider type recorded in a shared inventory. Confirm with each app owner which Okta features they actually rely on, because some may have no equivalent in the free edition.
Export user lists and attributes
Export the active user list from Okta. Okta documents three routes: the Password Health report CSV in the Admin Console, the community Rockstar browser extension, or the List Users API with a filter. The export carries profile data but not password hashes, so users will set new credentials during enrollment. Store the file under your data handling rules, since it contains personal data. The step is done when the record count matches Okta's active users and the attributes needed for authentik's user model are present.
Design authentik flows and providers
Map each inventoried app to an authentik provider: OAuth2/OIDC, SAML, LDAP, proxy, RADIUS or SCIM. Design the authentication flows, stages and policies that replace Okta's sign-on policies, including MFA stages and group-based bindings. Decide whether any source must be synchronized from an existing directory. Where you need connectors for Microsoft Entra ID or Google Workspace, confirm with authentik whether those are in the Enterprise edition, because the pricing page lists them as Enterprise-only. The step is done when a design document lists each provider, flow and policy, and each gap is either accepted or assigned an owner.
Stand up the authentik deployment
Deploy authentik in your own infrastructure using the supported installation path for your environment, Docker Compose for test and small production setups or Kubernetes for larger ones. The architecture uses a server container, a worker container and PostgreSQL, with no Redis since release 2025.10. Plan database capacity for the connection increase the release notes warn about. Confirm the current supported release line in the security policy before you choose a version. The step is done when the instance passes health checks, backups of PostgreSQL run, and administrators can sign in with break-glass accounts.
Pilot a small set of applications
Choose two or three low-risk applications that cover at least one OIDC app and one SAML app, and connect them to authentik with a test group of users. Run sign-in, sign-out, group-based access and MFA enrollment in a staging copy of each app where possible. Record every error and every configuration difference from Okta. The step is done when pilot users complete their normal tasks on authentik for a period your change board agrees, and the rollback procedure for each pilot app has been tested.
Re-federate SAML and OIDC applications
Move the remaining SAML and OIDC applications in waves. For each app, update the identity provider metadata, client ID and secret, redirect URIs, signing certificates and attribute mappings on the app side, then point it at the authentik provider. Keep the Okta integration in place until the app is confirmed working. The step is done when each app has a signed-off test record and its Okta integration is set to inactive, not deleted, so it can be restored.
Move LDAP and RADIUS clients
Repoint LDAP and RADIUS clients, such as VPN concentrators, Wi-Fi controllers, Linux hosts or network devices, to the authentik outposts. Okta does not provide these services in the same way, so each client needs its bind account, base DN, search filter and shared secret reviewed and tested. Check that group membership used for authorization matches what the clients expect. The step is done when authentication succeeds for a test account on every client type, and the old service account paths are documented for removal.
Plan password and MFA re-enrollment
Because password hashes are not available from the Okta export route, plan how users set new passwords and register MFA factors on authentik. Options include a staged enrollment campaign, a first-login enrollment flow, and helpdesk-assisted verification for high-privilege accounts. Confirm with your security team which factor types you will accept and how identity is proven during enrollment. The step is done when the enrollment flow is tested with a pilot group, the helpdesk procedure is written, and a remaining-users report tracks progress toward cutover.
Cut over and retire Okta sources
Schedule the cutover window with application owners, switch remaining users and apps to authentik, and keep Okta read-only for the agreed period to support reconciliation and rollback. After the period ends, disable Okta provisioning, revoke API tokens and retire the Okta AD agent or other connectors. Export the Okta configuration and audit logs you need for records before the subscription ends. The step is done when no active sign-ins go through Okta, the archived configuration is stored, and the open items list is empty or formally accepted.
Questions buyers ask before switching from Okta to authentik
What does switching from Okta to authentik cost?
The cost is the sum of the software edition, the infrastructure, the migration work and the operations that follow, and only the software edition has a published per-user rate. authentik's free Open Source edition carries no license fee, while the Enterprise edition is listed on the authentik pricing page at $5 per user per month billed annually plus $0.02 per external user per month. Infrastructure, PostgreSQL, implementation, app re-federation, testing and staff time are separate items. Costs rise with the number of applications, the custom flows and policies to rebuild, and whether you need Enterprise features. Ask DeployOpen for a fixed-scope written quote that lists each of these items separately.
How long does an Okta to authentik migration take?
The timeline depends on the number of applications, how many Okta policies and group rules must be rebuilt as authentik flows and policies, and how many users must re-enroll their MFA. Parallel running, where Okta and authentik both serve logins for a period, adds time but lowers cutover risk. Application owners also set the pace, because each SAML or OIDC integration needs testing in a non-production environment before cutover. No duration is fixed in this page. Agree a timeline with DeployOpen in the written scope, based on an inventory of your apps and policies.
What work does the migration need from our own staff?
Your staff own the decisions that only your organization can make, and they supply the knowledge that the implementation needs. Expect the identity team to confirm which applications are in scope, approve the mapping of Okta policies to authentik flows, and sign off on test results. Application owners must verify their own logins and claims. Security and compliance staff review access rules and evidence. Someone must also own the PostgreSQL database and the server hosting, since authentik runs on its own infrastructure. Agree these responsibilities in writing before work starts.
Can our team migrate from Okta to authentik without outside help?
A small team with Linux, container and identity experience can complete a migration alone, but the work is more demanding than a standard configuration. The main risks are incomplete inventories of apps and Okta policies, untested claim mappings, and cutover without a rollback plan. authentik's Docker Compose guide positions that setup for test and small-scale production, so the team must also plan for high availability and backups. An outside partner is most useful for the architecture, the migration plan, and a hardening review. DeployOpen implements, hardens, documents and supports self-hosted platforms in your environment, under a fixed-scope agreement.
Does authentik support the applications we run on Okta?
authentik supports the common integration patterns, and the coverage of your specific applications must be confirmed one by one. The free edition covers OAuth2/OIDC, SAML, LDAP, proxy, RADIUS and SCIM providers, which handles most web apps, legacy apps behind a proxy, and directory-bound services. Google Workspace and Microsoft Entra ID integrations are Enterprise features. Applications that depend on Okta-specific features, such as certain Okta Workflows or Access Gateway behavior, need a separate replacement plan. Build a list of each app's protocol and vendor-specific requirements, then check each against the authentik providers documentation.
Is the free authentik edition enough for our organization?
The free edition is enough when you need the protocols and providers it includes and can accept community-only support. The Open Source edition is listed as free with community Discord support only. Enterprise adds privileged access management, mTLS client certificate authentication, password history, enhanced audit logging, Google Workspace and Microsoft Entra ID integrations, and ticket-based support for subscriptions over $1k. Enterprise Plus adds dedicated support with SLAs, multi-instance support and FIPS compliance for FedRAMP requirements. Check your audit, support and integration requirements against these lists before deciding.
How are upgrades and security fixes handled in authentik?
Upgrades and security fixes are your operational responsibility unless you contract for support, and the project publishes a clear support window. authentik's security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and it announces security releases at least 24 hours in advance. Releases are named by year and month, so plan a regular upgrade cycle and test each release in staging. Note that the 2025.10 release removed Redis and moved its functions to PostgreSQL, and that the release notes warn of roughly 50% more PostgreSQL connections after upgrading. Confirm your patch process and support model in the written scope.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements, hardens and supports authentik inside your own infrastructure, so the decision between Okta and a self-hosted identity provider rests on written requirements rather than vendor claims. We start with the applications, directories and edition questions that decide whether the free authentik edition is enough.
How we scope
- Inventory Okta applications and map each to an authentik provider: OIDC, SAML, LDAP, RADIUS, SCIM, proxy or RAC.
- Identify which needs fall under the paid Enterprise edition, such as Entra ID or Google Workspace integration and privileged access.
- Agree the scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope.
How we build
- Deploy authentik on your own cloud accounts, data centers or private networks, with PostgreSQL as its only data store.
- Configure flows, policies, sources and outposts, and rebuild the Okta policies that matter to your environment.
- Test each re-federated application, MFA enrollment path and SCIM provisioning flow, and document the results.
How we hand over
- Deliver architecture notes, configuration records, runbooks and a cutover plan that your own team can follow.
- Document the edition decision, including which features rely on the paid Enterprise license and why.
- Walk your operations and security staff through backup, upgrade and incident procedures before handover.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan authentik version upgrades around the supported release lines named in its security policy.
- Ask any quote to separate one-time implementation from recurring retainer and Enterprise subscription costs.
