How to migrate from Auth0 to authentik in stages
If your Auth0 tenant serves applications and you want identity running in infrastructure you control, the move is usually staged rather than done in one cutover. The usual pattern is to add Auth0 to authentik as an upstream source, using the authentik Auth0 source guide, so users can keep signing in while applications move across one at a time. Auth0 stays live as the place where existing credentials are checked until each application, and then each user population, no longer depends on it. Effort depends less on user count than on three things: the number of applications and how each one is registered, the password approach you choose, and how much logic lives in Auth0 Rules and Actions. Each application needs its own authentik provider and application, with its redirect URIs, scopes and claims checked against what the app expects. Rules and Actions are not copied automatically. Each one has to be read, understood and rebuilt as an authentik flow stage, property mapping or policy, and any hidden dependency on a custom claim or an external call needs to be found before cutover. Ask any partner to inventory these items first. Before work starts, DeployOpen scopes the migration in writing: the application inventory, the source and cutover sequence, the password and export decisions, and the verification steps for each application. Confirm with your Auth0 administrators how your tenant is deployed and what plan it runs on, because export options differ by plan. Ask for the scope, deliverables and timeline in writing so you can compare it against an internal estimate.
What maps cleanly from Auth0 to authentik and what does not
This table compares Auth0 capabilities with their authentik counterparts, from applications and connections to rules, actions and custom databases. Read each row's verdict as a planning signal: clean maps still need testing in your tenant, while rows marked as needing a decision depend on choices only your organization can make.
| Auth0 capability | authentik equivalent | Verdict | What to confirm in your tenant |
|---|---|---|---|
| Applications as OIDC clients | OAuth2/OIDC provider bound to an application | Maps cleanly | Redirect URIs, allowed origins, token lifetimes and scopes match what each app expects |
| Applications as SAML clients | SAML provider with entity ID and ACS URL | Maps with rework | Entity IDs, signing certificates and attribute names must be recreated and tested per app |
| Enterprise connections (social and SAML/OIDC) | Sources, such as the Auth0 source used during cutover | Maps with rework | Auth0 stays as an upstream source while apps move; confirm claims and attribute mapping survive the hop |
| Users and profiles | Users with attributes and custom attributes | Maps with rework | Export format (NDJSON or CSV), metadata fields and custom attributes that need property mappings |
| Password hashes | Password hash import, if the hash format is supported | Needs a decision | Auth0 omits hashes from standard exports; paid-plan hash exports require a support request with no guaranteed date |
| Organizations | Groups and tenant-style scoping through groups, policies and bindings | Needs a decision | How org membership, org-level branding and org-scoped logins are modeled in your design |
| MFA factors and enrollment | Authenticator stages bound to flows | Maps with rework | Which factors you enforce, enrollment prompts and recovery paths; test each app flow |
| Roles and permissions | Groups and property mappings that emit claims | Maps with rework | Role names used in application authorization checks and how they become groups or claims |
| Rules and actions | Flows, stages, policies and property mappings | Needs a decision | Inventory each rule's logic, external calls and side effects; some code will need rebuilding by hand |
| Custom database connections | No direct equivalent to Auth0 custom database scripts; plan an external source or import | Needs a decision | Whether the legacy user store can be synced, federated or migrated, and who owns that work |
Tools to migrate from Auth0 to authentik
Four documented paths cover the move from Auth0: exporting user records, requesting password hashes, and federating Auth0 into authentik while applications cut over. Each path answers a different question, so most migrations combine two or three of them. Check what each one returns before you plan the cutover sequence.
Dashboard bulk user export
The Auth0 Dashboard can bulk export users in NDJSON or CSV format, which gives you profile attributes, identifiers and metadata for mapping into authentik users. It is the simplest route for a small or single-tenant move and needs no API scripting. It does not include password hashes, so users will still need a password path after import. Confirm which custom metadata fields the export contains before you design attribute mappings, because those fields will not appear in authentik unless you map them.
Management API export job
The create export users job (POST /jobs/users-exports) produces the same NDJSON or CSV output through the Management API, so the export can be scripted, repeated and run against a tenant on a schedule. Repeatable exports help when you run a staged cutover and need fresh user data near the switch date. Plan for an API client with the right scope, and check the job status and file download steps in the Auth0 docs before you automate them. The export still excludes password hashes.
Password hash export request
On paid plans, you can ask Auth0 support through a ticket to export password hashes. This is the only documented route that lets users keep their existing passwords after moving to authentik. Auth0 does not guarantee a delivery date, so start the request early and treat it as a dependency on the cutover plan. The option is not available on the Free plan, so teams on that tier must plan for password resets or federation instead. Ask which hash format you will receive and whether your authentik version can import it.
authentik Auth0 source
The authentik Auth0 source federates Auth0 as an upstream identity provider over SAML or OpenID Connect. Applications can move to authentik providers one at a time while users keep signing in through the familiar Auth0 login, which reduces risk during cutover. Federation does not migrate user records or hashes, so accounts are created in authentik on first login or through a separate import. Decide early whether Auth0 stays active as a source after the last application moves, and confirm the attributes authentik receives from Auth0.
Password options decide how users experience the cutover
The password approach is the first migration decision to make, because Auth0's standard user export does not include password hashes. Without hashes, every user who signs in to authentik must either be federated back to Auth0 for their login, or be asked to set a new password. Choose the password path before you write the cutover plan, since it sets the timeline, the user communication and how long Auth0 stays in production. The first option is to request password hashes from Auth0 support. Auth0 documents that hash exports are not in the standard export, that paid plans request them through a support ticket, and that the option is not available on the Free tier. Auth0 does not guarantee a delivery date, so this path can add an unpredictable wait to the project. Ask Auth0 directly for the hash format it will deliver, the algorithm parameters, the delivery terms and whether the export covers every connection type you use. Then import a small copy of the data into a test authentik instance and confirm that a known test user can sign in before you commit to this route.
The second option is to federate logins to Auth0 during the transition. In authentik, Auth0 can be configured as a federated source over SAML or OpenID Connect, so a user who signs in through authentik is passed to Auth0, and the password is verified there. This keeps user friction low and avoids a reset, but it means Auth0 stays in the login path, and you keep paying for its plan for as long as those users remain. Plan for that cost and for a retirement date, and record which users have been migrated so the federation can be removed once the last active user has moved. The third option is to require password resets. It is the simplest technically and gives you a clean break from Auth0, but it puts the work on the user and on your help desk, and it needs a tested reset flow in authentik before go-live. Many teams combine the options, for example by importing hashes for users who sign in often and forcing resets for dormant accounts. Whichever mix you choose, confirm the approach with your security team, since it determines how credentials move between systems.
Which password path fits which Auth0 estate
On a paid Auth0 plan, you can ask Auth0 support for a password hash export through a support ticket. Auth0 does not guarantee a delivery date, so the request belongs at the start of planning, not at cutover. Once the hashes arrive, the sequence is to import users and hashes into authentik, confirm that sample logins succeed, and then switch applications to authentik as the identity provider. Users who sign in with the same password usually notice nothing beyond the new login page.
- Ticket lead time: File the request early and treat delivery as uncertain until Auth0 confirms it.
- Hash format: Confirm with Auth0 which hash algorithm the export uses, then confirm authentik can import that format before relying on it. Formats that need conversion add work.
- Test logins: Pick a sample of accounts across password ages and hash types and verify sign-in in a staging authentik instance.
- Fallback: Decide whether users who fail after cutover get a reset prompt, and who owns that support queue.
- Exported file handling: Treat the hash export as sensitive data, with restricted access and encrypted storage in your environment.
Before choosing this path, confirm the plan tier, the ticket process and the expected hash format in writing with Auth0.
The Free plan does not offer password hash exports, so you cannot carry existing passwords into authentik directly. The usual alternative is to move user profiles and identifiers, then have users set a new password at first sign-in or through a reset flow. This changes the user experience and needs a communication plan, because every database user will meet a password step they did not expect.
- Profile export: Use the Dashboard or the Management API user export job to pull profiles in NDJSON or CSV, and map fields to authentik attributes.
- Reset flow: Build a recovery or enrollment flow in authentik that sends a one-time link to each migrated user.
- Staged cutover: Consider keeping Auth0 as a federated source for a period so users can sign in there until they are moved, if your tenant and apps allow it.
- Support load: Estimate reset volume with the business owners and staff the help desk for the cutover window.
- Account states: Decide how to handle blocked, unverified or inactive accounts so they do not reappear active in authentik.
Before choosing this path, confirm your current plan tier, whether an upgrade would change the decision, and which user groups can tolerate a reset.
Many Auth0 tenants mix connection types: enterprise SSO connections, social logins and a database connection holding usernames and passwords. Each type has a different password story. Enterprise and social users never had an Auth0 password to migrate, so their identity comes from the upstream provider. Only database users raise the hash question. Treating the estate as one group usually causes errors, so split the population first.
- Connection inventory: List every connection, the users attached to it and whether it is a database, enterprise or social source.
- Federated users: Keep enterprise and social logins pointed at their upstream providers through authentik sources, rather than copying passwords.
- Database users: Apply the hash or reset path from the earlier tabs to this group only.
- Account linking: Confirm how users with more than one connection map to a single authentik account, and resolve duplicates before import.
- Application mapping: Note which applications accept which connection, since some may rely on connection-specific behavior.
Before choosing a path, confirm the count of users per connection type and whether any users appear under more than one connection.
Sequence for a migration from Auth0 to authentik with a parallel run
This sequence moves sign-in for each Auth0 application to authentik in controlled stages, so that every cutover has evidence behind it and a rollback path. Each phase ends at a decision gate that someone signs off on before the next phase starts.
Inventory tenants, applications, connections and custom domains
Start by listing every Auth0 tenant, application (client), connection, enterprise connection and custom domain, along with the owner and the sign-in protocol each application uses. Record which Rules and Actions run on each login, what claims they add to tokens, and which applications depend on them. Note the tenant region, since public cloud tenants are created in a fixed region and the tenant name cannot be changed later. Gate: the platform owner and each application owner confirm the inventory is complete, and every Rule or Action has a named replacement plan (a flow stage, property mapping or policy) before the pilot is chosen.
Stand up authentik and pick a low-risk pilot
Deploy authentik in the infrastructure you control and configure the Auth0 source as a federated identity provider using SAML or OpenID Connect, following the Auth0 source guide. Choose one internal or low-impact application with a simple claim set and few Rules or Actions. Create the matching authentik provider and application for it, and test sign-in in a non-production environment with a small group of test accounts. Gate: the pilot team confirms sign-in, logout and claim values match what the application expects, and the rollback step (pointing the application back to Auth0) has been rehearsed.
Run the pilot application in production under parallel operation
Move the pilot application to authentik while Auth0 remains active for every other application and for the pilot's fallback. Users sign in to authentik, which federates to Auth0 for credentials during the transition, so Auth0 and authentik serve sign-ins at the same time. Monitor authentication errors, token claim differences, session length and support tickets for a defined observation period agreed before go-live. Gate: error rates and support volume stay within thresholds the application owner set in advance, and no user-facing claim is missing or changed. Review the evidence before the next application is scheduled.
Cut over remaining applications one at a time
Migrate the remaining applications in small batches or one by one, ordered from lowest to highest business risk. For each application, move its sign-in to authentik, rebuild the Rules and Actions it depended on as authentik flows, stages and property mappings, and confirm the claims or SAML attributes it receives. Export user records and decide the password approach with the Auth0 account team before the batch, since standard exports do not include password hashes and hash exports are requested through a support ticket with no guaranteed delivery date. Gate: each application has a written rollback criterion, such as failed sign-in rate or missing claims, and a named owner who can trigger rollback within the change window.
Verify user population and password handling
Before the final batch, reconcile the user population between the Auth0 bulk export (NDJSON or CSV) and authentik, checking counts, unique identifiers, email verification status, linked identities and custom metadata. Confirm how each user will authenticate after cutover, whether through a retained Auth0 federation, an imported password hash, or a forced reset with a recovery flow. Document which users cannot be migrated automatically, such as those relying on social connections or MFA enrollments that must be re-established. Gate: the reconciliation report is signed off by the identity owner, and every exception has a documented handling path.
Decommission Auth0 after logs and sessions are clean
Once every application has run on authentik through its observation period, confirm that no traffic still reaches Auth0 by reviewing tenant logs and application configuration. Remove the Auth0 federation source from authentik only after active sessions have expired and no application or script still calls Auth0 endpoints. Export and archive the Auth0 configuration, Rules and Actions, and logs your audit or retention policy requires, then decide with the contract owner how the tenant and any Private Cloud or enterprise subscription are closed. Gate: the security and compliance owners sign off on the archive, and the log review shows no unexpected sign-ins through Auth0 for the agreed period.
What drives the cost and duration of an Auth0 move
This table lists the factors that change the effort of moving applications from Auth0 to authentik, and whether each one is paid once or recurs. Use it to see which answers you need before requesting a quote, since most drivers are set by your own Auth0 tenant and internal change process rather than by the platform itself.
| Driver | Why it changes effort | One-time or recurring, and what to ask for |
|---|---|---|
| Applications and protocols | Each Auth0 application maps to an authentik provider and application, and SAML and OIDC clients need different settings and testing. | One-time. Ask for a per-application inventory with protocol, callback URLs, claims and logout behavior. |
| Password approach and hash availability | Auth0 standard exports omit password hashes, so the option to keep existing passwords depends on what Auth0 supplies for your plan. | One-time. Ask whether the quote assumes hash export, forced resets or a staged login through Auth0 as a source, and who opens the Auth0 support request. |
| Rules and actions | Each rule or action that enriches tokens, blocks logins or calls external services must be rebuilt as an authentik flow, policy or property mapping. | One-time for the rebuild, with ongoing review if logic changes. Ask for a list of every rule and action with its purpose. |
| Custom database connections | Logic that checks users against your own database must be reproduced in authentik, typically through a source or an integration, and tested against real credentials. | One-time. Ask how the existing database and its password scheme will be reached during cutover. |
| Enterprise connections and organizations | SAML or OIDC enterprise connections and per-customer organizations each need their own source, mapping and routing decisions. | One-time for setup, recurring when customers are added. Ask how new connections will be onboarded after go-live. |
| MFA enrollment needs | Users enrolled in Auth0 MFA may need to re-enroll in authentik, and factor choices affect help desk load and testing. | One-time for the migration, with recurring help desk support during the enrollment window. Ask who handles enrollment and recovery requests. |
| Number of environments | Development, staging and production each need the Auth0 source, client settings and flows configured and verified separately. | One-time per environment, plus recurring sync of configuration changes. Ask whether configuration will be managed as code. |
| Internal review and change controls | Security review, change advisory approvals, test sign-off and cutover windows set the pace more often than technical work does. | Mostly one-time, but recurring for each later change. Ask for the approval steps and the rollback plan the quote must cover. |
What usually goes wrong in an Auth0 to authentik move
Most failed Auth0 migrations break at the edges: user data that arrives incomplete, claims that applications no longer receive, and logic that lived in Auth0 rules or actions and was never written down. Each card below names one risk, the step that prevents it, and the check to run before any application cuts over.
Password hashes arrive late or not at all
Auth0 does not include password hashes in standard user exports. Hash exports go through a support ticket on paid plans, the option is not available on the Free tier, and Auth0 does not guarantee a delivery date. Ask for the hash export as early as possible, and confirm in writing whether your plan and tenant qualify. Until hashes arrive, plan for a password reset path or a staged source so users can still sign in.
Claims that applications no longer receive
Applications often read custom claims, roles or namespaced attributes that a Rule or Action added to Auth0 tokens. In authentik, those values come from property mappings and scopes that you define, so a missing mapping produces a token that looks valid but lacks the field. Build a claim inventory from each application's token parser, then compare decoded tokens from Auth0 and authentik for the same test user before cutover.
Redirect URIs and logout breaking at cutover
Redirect URIs, allowed logout URLs and CORS origins must match exactly in the new provider. A mismatch often shows as a generic login error, and a logout that works in Auth0 may leave a session active in authentik or an application. Copy every callback and logout URL from the Auth0 application settings, register them on the matching authentik provider, and test sign-in and sign-out in a staging environment for each application.
Rules and actions holding hidden business logic
Auth0 Rules and Actions often contain approval checks, domain allowlists, tenant-specific branching or account linking that nobody documented. Those behaviors do not carry over automatically. Export every Action and Rule, list what each one does to the user, token or session, and rebuild each item as an authentik flow stage or policy. Ask the owning team to sign off each rebuilt behavior before cutover.
User identifiers changing during import
Auth0 user IDs take the form of a connection prefix and a value, such as a database or social connection prefix. authentik assigns its own internal identifiers, so any application that stores the Auth0 subject claim will see a different value for the same person. Decide early whether applications will key on email, a custom stable attribute or a mapped subject, then test account linking on a sample of real-shaped records before the full import.
Users locked out during MFA re-enrollment
If MFA factors are not carried over, users must enroll again at first sign-in, and users without access to their old device can be locked out. Confirm which factors your Auth0 tenant uses and which authentik stages will replace them. Schedule a supervised enrollment window, document a recovery path that your help desk can run, and pilot the enrollment with a small group of test accounts before wider rollout.
What authentik requires and what stays on your side
Before you commit to cutover, confirm what you take on once authentik replaces Auth0. The core of authentik is released under the MIT license, but code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory. Review both, with your legal team, against the features your Auth0 tenant actually uses. Auth0 features that map to enterprise-only authentik capabilities include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication and enhanced audit logging. Inventory every connection, Organization and login rule in your tenant, mark the ones that depend on those capabilities, and price the enterprise subscription for them before the migration plan is fixed. The authentik pricing page lists the current tiers and per-user terms, which you should confirm in writing with the vendor.
Next, plan the deployment shape. A standard authentik deployment has a server container (core plus an embedded outpost), a worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. The Docker Compose guide targets test setups and small-scale production, and it calls for at least 2 CPU cores and 2 GB of RAM as a starting point. For production on Kubernetes, the Helm chart's bundled PostgreSQL is intended for demonstration and testing, so budget for a separately managed PostgreSQL instance with its own backup and high availability design. Your team also keeps operating the platform: applying upgrades, patching the host and containers, rotating the secret key, and monitoring the worker. Read the authentik security policy to see which versions receive security fixes and how much notice the project gives before a security release, then set a patch window that fits that notice.
Questions buyers ask before moving from Auth0 to authentik
What does moving from Auth0 to authentik cost?
The cost is mostly the labor to inventory applications, rebuild Auth0 rules and actions as authentik flows and policies, test each application and cut it over. Self-hosted authentik's Open Source edition has no license fee, but the infrastructure you run it on, the staff time and any external help are real costs. Enterprise features, such as Microsoft Entra ID or Google Workspace integrations, are priced separately and only apply if you need them. Ask any partner for a quote built from a written scope that lists applications, custom logic, data export and testing. Auth0's own costs, which are priced by monthly active users, stop when you retire the tenant, so confirm your contract terms and notice periods with Auth0 before you plan the cutover date.
How long does an Auth0 to authentik migration take?
The duration depends mostly on how many applications you have, how much custom logic sits in Auth0 rules and actions, and how many user populations and connections need to move. A team with a short list of standard OIDC applications and no custom logic will finish far sooner than one with dozens of SAML integrations and bespoke post-login actions. Start with an inventory of every application, connection and action, because that list sets the schedule. Ask any partner to base the timeline on that inventory and to show which applications are cut over first.
Can our own team migrate from Auth0 to authentik without a partner?
A capable platform or security team can do the work in-house if it has experience with OIDC and SAML, PostgreSQL-backed services and the Auth0 management tooling. The hardest parts are usually not the protocol setup but the hidden behavior in custom actions, claim mappings and session rules that applications depend on without anyone documenting them. Be honest about bandwidth during the cutover window and about who owns the server, backups and upgrades after go-live. A fixed-scope engagement can cover some or all of these tasks, and the written scope makes it clear which parts stay with your team.
What do we need from our staff and from Auth0 support?
Your staff need to provide application owners who can confirm redirect URIs, claims, scopes and logout behavior, and an administrator who can export users and manage the Auth0 tenant. Security or compliance staff should approve the control design and sign off on test evidence. Auth0 support matters mainly for password hash exports: according to Auth0's documentation, paid plans request password hash exports through a support ticket, delivery is not guaranteed on a date, and the option is not available on the Free tier. Open that request early, because it sits outside your control.
Can we keep existing user passwords when moving to authentik?
Possibly, but only if you can obtain password hashes from Auth0 and the hash format can be imported. Auth0's standard user exports do not include password hashes, so you must request them separately as described above. If hashes are delivered, authentik can import Django-format hashes, and other formats may need conversion first. If hashes are not available, the usual path is to keep users on Auth0 as a federated source during cutover and let them set a new password in authentik through an enrollment or recovery flow. Confirm the hash format with Auth0 before you design the import.
Can Auth0 stay running while applications move to authentik?
Yes, the usual pattern is to add Auth0 as a SAML or OIDC source in authentik and move applications one at a time. authentik's Auth0 source guide describes configuring Auth0 as a federated identity provider, so users can keep signing in through Auth0 while each application is repointed to authentik. Plan for an overlap period in which both systems run, including who owns each application's configuration at each stage. Keep Auth0 active until every application, user population and recovery path has been verified.
What happens to MFA enrollment during the move?
MFA enrollments stored in Auth0 do not transfer automatically, so users will generally need to enroll a second factor again in authentik. Plan a enrollment window, communicate it to users and decide whether a second factor is required at first sign-in. Where Auth0 still handles the login through a federated source, its own MFA prompt may continue to apply until the cutover is complete. Confirm exactly which factor types you will support in authentik and how recovery works for users who lose a device.
Does authentik licensing change the total cost of the move?
The Open Source edition of authentik is free to use, and its repository places most of the code under the MIT license, while code in the authentik/enterprise/ directory is under a separate enterprise license. 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. Enterprise features include Google Workspace and Microsoft Entra ID integrations, mTLS, password history and enhanced audit logging. Compare those figures with Auth0's plan pricing only after you decide which features you need, and check the license terms with your legal team.
How DeployOpen scopes and delivers an Auth0 migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so an Auth0 move to authentik is scoped in writing before any work starts. The work covers the applications, user data, password options and Auth0 Actions that your team agrees to bring across, and the handover describes what your team runs afterward.
How we scope
- We inventory every Auth0 application, connection, Action and Rule that the written scope covers for this migration.
- We record which applications move to authentik OIDC or SAML providers and which keep Auth0 as a source during cutover.
- We agree the user export method and password option in writing, including whether Auth0 password hash exports are requested and when they may arrive.
How we build
- We deploy authentik in your infrastructure, with PostgreSQL and the server and worker containers sized for your user population.
- We configure Auth0 as a federated source where cutover needs it, then rebuild Actions and Rules as flows, policies and property mappings.
- We test each application's login, logout, token claims and group mapping against a staging copy before any production switch.
How we hand over
- We deliver configuration documentation covering providers, applications, flows, policies, source settings and the rollback steps for each application.
- We record which Auth0 features had no direct equivalent, so your team can decide how each one is handled after cutover.
- We walk your administrators through daily operations, backups and the upgrade path for the authentik version you deploy.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A quote follows from the written scope, so ask for it to list each cost component, what is one-time and what recurs.
