Auth0 vs Keycloak: when each one fits customer login
If your renewal, a change to Auth0's monthly active user pricing, a data residency rule or lock-in is pushing you to look at alternatives, the short answer is this: Auth0 fits teams that want a hosted service and accept MAU pricing, while Keycloak fits teams that want self-hosted Apache-2.0 software and have the people to operate it. The decision turns on five points: how fast your monthly active users are growing, where customer identity data must physically live, whether your customers need separate organizations with their own members and login connections, which protocols your applications and partners require, and how much in-house operations capacity you can commit to patching and upgrading an identity cluster.
Start with the cost model and the operating model, because they change together. Auth0 bills by monthly active users and the Enterprise add-ons, so your bill rises with customer growth and falls only if you negotiate or reduce users. With Keycloak, the software cost is zero, but you pay for the infrastructure, a PostgreSQL database that Keycloak supports (versions 14 to 18), high availability design that needs a synchronously replicated database, staff time, and support if you buy it from a vendor such as Red Hat. Ask Auth0 for a written quote that maps your projected users to plan limits, and ask your team to estimate operations hours for upgrades, which Keycloak ships four times a year in minor releases according to the project's plans.
Check the tenant model and protocol needs before you commit. Auth0 uses tenants and Organizations for B2B customers, while Keycloak uses realms, and its Organizations feature covers per-customer members and identity providers. Confirm that your applications need only OIDC and OAuth 2.0, or also SAML 2.0 for enterprise customers, and that the social and enterprise identity brokering your customers expect is available in the Keycloak version you plan to run. Also confirm how you will move users and password hashes out of Auth0, since hash export is a support request on paid plans and is not guaranteed a delivery date, so start that request early in any migration plan.
Which option fits which scenario
This table matches common Auth0 situations to the option that usually fits better and names the condition under which the other option wins. Read each row against your own user counts, residency rules and operations capacity, since the right answer shifts with those inputs.
| Scenario | Better fit | Reason and when the other option wins |
|---|---|---|
| Small app with few users | Auth0 | A hosted tenant needs no cluster, database or patching, so a small team can ship login quickly. Keycloak wins if you already run Kubernetes and want no per-user meter. |
| Fast-growing consumer MAU | Keycloak | Auth0 cost follows monthly active users, so growth raises the bill directly. Self-hosted Keycloak shifts cost to infrastructure and staff time, which pays off only if you can run it reliably. |
| B2B SaaS with per-customer SSO | Keycloak | Keycloak realms, identity brokering and its Organizations feature can model each customer's identity provider and members. Auth0 is simpler to configure if your team lacks the skills to manage many realms and connections. |
| Strict data residency | Keycloak | Running Keycloak in your own or an approved datacenter keeps customer identity data and logs under your control. Auth0 can fit if a regional tenant or private deployment meets your legal review. |
| Existing Active Directory or LDAP estate | Keycloak | Keycloak has built-in user federation with LDAP and Active Directory servers, so existing directories can stay the source of truth. Auth0 fits if your users are mainly external customers with no internal directory to connect. |
| Team with no platform operations | Auth0 | Auth0 handles upgrades, availability and backups as a service. Keycloak needs a database, high availability design, upgrade testing and monitoring, so choose it only if someone owns those tasks. |
How Keycloak realms map to Auth0 tenants and Organizations
The first design decision is that a Keycloak realm is the isolation unit where Auth0 uses a tenant. Each realm has its own users, clients, roles, identity providers, authentication flows and signing keys, so a realm is the boundary you would use to separate environments or a separate customer population. Auth0's Organizations feature is different: it sits inside one tenant and groups members, roles and enterprise connections per customer. Keycloak's *Organizations* feature (available in recent releases, so confirm the exact status in your target version) takes a similar approach within a single realm. It lets you attach members, a domain and an identity provider to each organization, and it routes users with a matching email domain to their organization's login. Before you map your tenant, list every Auth0 tenant and every Organization, then decide which of them need a realm of their own and which can share one realm with Organizations.
Tokens and login behavior change in ways your application team must test. Organization membership claims in Auth0 tokens will not match Keycloak's claim names or structure by default, so check how your API validates the org_id or equivalent claim and where the organization identifier appears. Auth0 Actions run as code in the login pipeline, while Keycloak uses authentication flows made of configurable executions plus custom SPI providers when built-in steps are not enough. Logic that Auth0 hosts in Actions, such as adding claims or enforcing a rule for a specific customer, usually needs a custom mapper, a protocol mapper or a small provider written in Java. Confirm which of your Actions depend on Auth0 data that Keycloak does not expose.
Test one complete B2B case before committing to a model. Create two organizations in a non-production realm, give each an identity provider and a domain, add a user who signs in through each path, and confirm the tokens your APIs receive. Include a user who belongs to two organizations, a user whose enterprise login fails, and a support administrator who needs cross-organization visibility. Ask your DeployOpen or in-house team to document the result as a written decision record, and compare it against the Keycloak server administration guide for the exact configuration options in the release you plan to run.
Moving users and password hashes out of Auth0
This sequence gets user profiles and, where Auth0 releases them, password hashes out of an Auth0 tenant and into a Keycloak realm, with checks at each stage so cutover does not depend on assumptions about hash compatibility. The output is a tested import and a documented list of users who will need a password reset.
Inventory the tenant and its user sources
Before any export, list the Auth0 connections that hold users: the Auth0 database connection, social connections, and enterprise connections such as SAML or OIDC identity providers. Record user counts per connection and which applications use each one. Your team owns this inventory, and the output is a sheet that maps each Auth0 connection to the Keycloak identity provider or user federation setting that will replace it. Users who sign in only through a social or enterprise connection usually do not have a password hash to move, so they should be counted separately.
Run the bulk user export job
Start the export from the Auth0 Dashboard or through the Management API create export users job (POST /jobs/users-exports), choosing NDJSON or CSV. Auth0's bulk export documentation describes both formats. Your engineer downloads the file once the job completes and stores it in an encrypted location with restricted access, because it contains personal data. The check is that the record count in the file matches the inventory from the previous step. Standard exports do not include password hashes, so this file alone is not enough for users to keep their passwords.
Request the password hash export from Auth0 support
Password hashes are a separate request. On a paid plan, your organization opens a support ticket asking Auth0 to export the hashes for the database connection. The option is not available on the Free tier, so a Free tenant cannot move hashes this way. Auth0 does not guarantee a delivery date, so ask the vendor for its current expected handling of the request and plan the cutover around that uncertainty. The output is a hash file from Auth0 that your security team must handle with the same controls as the profile export.
Confirm hash format compatibility with Keycloak
Before importing, check which password hash algorithms and parameters appear in the Auth0 export, and whether Keycloak's password policy and credential model can verify them. Keycloak's import mechanism accepts realm JSON that can carry credentials, but you should confirm with the Keycloak documentation for your target version and test with a sample of accounts from each algorithm present. Ask Auth0 which hash format the export uses. The check is a written compatibility result for each hash type. If a hash type cannot be verified, plan a forced password reset for those users rather than assuming they will sign in.
Prepare the Keycloak realm and import the users
Create a target realm in a non-production Keycloak instance and recreate clients, roles and identity providers from the inventory. Then import the users with the realm import mechanism (kc.sh import), which reads realm JSON. Keycloak's documentation warns that export and import have limitations as a backup mechanism and that all nodes must be stopped while the process runs, so schedule this in a maintenance window on a staging cluster first. The output is a realm whose user count and group membership match the Auth0 export.
Test sign-in with migrated accounts
Using a test set of accounts that covers each hash type, each connection type and users with multi-factor enrollments, sign in through the migrated applications. Your QA team records which logins succeed with the original password, which need a reset, and which fail. Check that users who came through social or enterprise connections are linked to the right identity provider and not duplicated. The output is a signed test log with the failure list, and any hash type that failed compatibility should be reflected in the reset plan.
Plan the password reset and cutover path
Using the test results, decide which users keep their passwords, which need a forced reset, and how users reach the reset flow after cutover. Communicate the plan to support staff and to application owners, and keep the Auth0 tenant available until the migrated realm has passed the test log. Your team documents who has access to the exported files and when they are deleted, since those files contain personal data and credentials. The finished output is a cutover runbook with a rollback point and a list of retained and deleted export files.
Where customer identity data lives and who can reach it
Moving customer login off Auth0 changes where user records, password hashes, admin credentials and logs sit. The cards below cover the decisions that follow from that change, so the team can match the hosting model to its data residency and audit obligations.
Auth0 data location and regional hosting
Auth0 is a hosted service, so user records, logs and tenant configuration sit in the tenant regions Okta operates. Before comparing costs, ask Okta in writing which regions your tenant can use, whether a dedicated or private deployment is available, and where backups and support access are processed. Those answers define the baseline you are moving away from.
Keycloak hosting in your own environment
A Keycloak deployment runs in your cloud account, data center or air-gapped network, so the location of user records and password hashes is a decision you make and document. You choose the database, the regions and the backup targets. Check that the database you select is on Keycloak's supported list and that replication and backups stay within the regions your data rules allow.
Admin access to the identity platform
In Auth0, Okta staff access to your tenant is governed by Okta's own controls, and your team's access is governed by tenant roles. In a self-hosted Keycloak, the people who can change realms, clients and signing keys are whoever holds realm administration rights, plus anyone with cluster or database access. Define named administrators, separate platform admins from realm admins, and record who can reach the database directly.
Logs, metrics and audit trails
Auth0 logs are retained and queried through its platform, with retention depending on your plan. With Keycloak, login events and admin events are only as durable as the sinks you configure. Decide where logs go, how long they are kept, and who can read them, and confirm that user identifiers in logs meet your privacy rules. Keycloak exposes metrics you can route into your monitoring stack.
Backup and export as a data control
Auth0 exports users as NDJSON or CSV, and password hashes require a separate support request on paid plans. Keycloak realm export is documented as having limitations as a backup mechanism, and it requires all nodes to be stopped while it runs. Plan a backup approach at the database level, test restores, and treat the realm export as a migration tool rather than your only copy.
Compliance evidence and who produces it
Auditors will ask for evidence of access reviews, change records, logging and data location for both platforms. Okta provides its own certifications and reports, and those cover only the service Okta runs. For a self-hosted Keycloak, DeployOpen can prepare the controls, configuration and evidence, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
What running a Keycloak cluster involves
Keycloak's license costs nothing, but the platform is a stateful service that someone must operate. The first decision is the database. Keycloak's documented production databases include PostgreSQL (14 to 18), MariaDB, MySQL, Microsoft SQL Server, Oracle Database, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The bundled dev-file database is for development only. Confirm your chosen engine and version against the Keycloak database guide before sizing hardware, and plan to run the database under your own backup and patch cycle, since Keycloak does not manage it for you. High availability is the larger effort. Keycloak documents three architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) that do not need an external Infinispan cluster, and the deprecated multi-cluster v1 design that used a separate Infinispan cluster per site. Both supported designs depend on a synchronously replicated database, so a cross-site setup has to meet that requirement before any node is deployed. Your team will also need to run the metrics and health endpoints, load balancing and failover tests, and a documented runbook for node loss. Upgrades are where cluster operators spend their time. Since Keycloak 26.0, the project ships four minor releases a year and a major release every two to three years, and says breaking changes in a minor release are opt-in. The current release is 26.8.1, published October 13, 2026. Schema migration runs automatically at startup by default, but the upgrading guide suggests manual SQL for large deployments. For the Operator, the documentation strongly recommends manual approval mode for updates. If you need vendor-supported builds, Red Hat build of Keycloak is Red Hat's supported distribution of the same project, which replaces Red Hat Single Sign-On. Ask Red Hat which version it currently supports, because its product page reported 26.6 as the latest at the time of the research.
What Auth0 MAU pricing costs versus running Keycloak
Auth0 charges a subscription that scales with monthly active users and plan features, while self-hosted Keycloak moves the cost into infrastructure, database, operations and people. The cards below separate what is paid to whom, what recurs, and what changes the total, so you can ask vendors and integrators for comparable quotes.
Auth0 subscription by MAU and plan
Auth0 bills a recurring fee that rises with monthly active users and with the plan features you enable, such as Organizations, enterprise connections and add-ons. Ask for the price at your projected MAU count for three years, and list which features sit on which tier, because the feature mix often moves you to a higher plan than the user count alone suggests. Confirm how the vendor meters users who sign in only once per month and how overages are billed.
Keycloak software licensing
Keycloak is licensed under Apache 2.0, so there is no per-user license fee for the server itself. Costs appear only where you buy support from a vendor or pay an integrator. Red Hat build of Keycloak is a supported distribution with its own subscription, so confirm whether you need that support contract or can run the community release under your own operating model.
Database and hosting infrastructure
Keycloak needs a supported production database, and the high availability designs require a synchronously replicated database. Hosting, storage, backups and network egress are recurring costs that grow with session volume and retention. Ask your cloud or data center team to price a managed PostgreSQL service in each availability zone you plan to use, and compare that with the MAU fee at your expected growth.
High availability and monitoring
A customer login service that goes down blocks sign-in for every application behind it, so the Keycloak cluster, its load balancer and its metrics stack become recurring capacity you must pay for. Keycloak documents metrics support, which you still have to collect, store and alert on. Price the spare nodes, observability tooling and on-call coverage separately, since these are the costs most often missing from first estimates.
Upgrades, patching and testing
Keycloak publishes four minor releases a year, and the Operator documentation recommends manual approval for operator updates. Each upgrade needs a staging environment, regression tests for your login flows and a rollback plan, and the database schema migration must be planned for large deployments. This is recurring work that scales with the number of realms, clients and custom authenticators you run.
Engineering time and support
Your platform team, or a partner such as DeployOpen on a fixed-scope or retainer basis, is the largest variable cost. Initial deployment, identity brokering setup and data migration are mostly one-time, while patching, incident response and support contracts recur. Ask each bidder for a written scope that separates build, migration, run and support, and for the named roles and hours behind each line.
What a switch from Auth0 to Keycloak involves at a high level
The sequence moves customer login from an Auth0 tenant to Keycloak realms in stages, so users keep their accounts and passwords while applications switch to standard OIDC with a tested rollback path.
Inventory tenant configuration and applications
List every Auth0 application, API, database connection, social and enterprise connection, Action, Rule, custom domain, email template and Organization. Record which applications call which APIs and which scopes and claims each one depends on. This work is usually done by the platform team with input from application owners. It is done when each item has an owner and a planned Keycloak equivalent, and the list of Actions and Rules shows which logic must be rewritten rather than copied.
Export users and check what the export contains
Run the bulk user export job in the Auth0 Dashboard or through the Management API (POST /jobs/users-exports) in NDJSON or CSV format. Standard exports do not include password hashes, so request the hash export through a support ticket on a paid plan and confirm the plan supports it, since Auth0 does not guarantee a delivery date. Store exports in an encrypted location under your own access controls. The step is complete when record counts match the Auth0 dashboard and the hash file has been received and checksummed.
Design the realm and client model
Decide whether one realm serves all customers or each B2B tenant needs its own realm, and map Auth0 Organizations to Keycloak's Organizations feature where that fits. Define clients, redirect URIs, scopes, protocol mappers that reproduce the token claims applications expect, and role and group structures. Document the decisions in a design record that security and application owners sign off. The output is a realm design that can be reproduced from configuration files.
Set up identity providers and federation
Recreate each social login and enterprise connection as a Keycloak identity provider, including OIDC and SAML settings, attribute mappers and first-login flows. Where directories such as Active Directory or LDAP hold employee identities, configure user federation. Test each connection with test accounts and record the expected claims. The step is done when every connection on the inventory has a working test login in a non-production realm.
Import users and test password hashes
Import users into a staging realm with the import tooling and confirm how the exported password hashes are handled. Keycloak needs a hash algorithm it can verify, so test a sample of accounts from each hash type in the export, including accounts with MFA enrolled. Confirm that users who have no hash are sent to a controlled reset path. The step is complete when test logins succeed with original passwords for sampled accounts and failures are logged and understood.
Switch applications to standard OIDC
Replace Auth0 SDK calls with standard OpenID Connect libraries or the Keycloak adapter for each application, and rewrite Actions and Rules as Keycloak mappers, authentication flows or application code. Update issuer URLs, JWKS endpoints and token validation in APIs. Run each application against staging and verify token contents and authorization decisions. The output is a passing test suite and a signed-off list of claim changes for each application.
Run in parallel and cut over
Keep Auth0 active while a limited group of users or one application signs in through Keycloak, and compare login success, error rates and support tickets. Plan the production export and import window with the cluster stopped as the Keycloak documentation requires for realm import and export, and keep a dated rollback plan that restores the Auth0 login path. Cut over when monitoring shows stable logins and the rollback has been rehearsed.
Decommission Auth0 and keep the evidence
After a stable period agreed in advance, remove Auth0 applications, revoke management API credentials, disable custom domains and retire the tenant or downgrade it as your contract allows. Retain exports and logs according to your retention policy and archive the design record, test results and cutover approvals for audit. The step is complete when Auth0 access is revoked, the subscription is closed in writing and the evidence pack is stored.
Questions buyers ask before choosing Keycloak over Auth0
How does the cost of Keycloak compare with Auth0 MAU pricing?
Keycloak has no license fee, so the comparison comes down to what you pay for the infrastructure and the people who run it versus what Auth0 bills per monthly active user. Auth0 costs scale with active users and with the plan tier and add-ons you need, which your Auth0 contract or order form will show. Keycloak costs are one-time setup plus recurring hosting, database operations, monitoring, patching and staff time, plus any support subscription you choose. The main drivers are user growth, how many high availability sites you run, how often you upgrade, and whether you buy vendor support. Ask any provider for a quote built from a written scope that lists each component separately, so you can compare line by line against your current Auth0 invoices.
Can our team migrate from Auth0 to Keycloak without outside help?
Yes, a capable team can do it, but the work has several parts that need different skills. The Auth0 side requires running the bulk user export job, which produces NDJSON or CSV files, and you must request password hashes separately through Auth0 support on a paid plan. On the Keycloak side you import realms from JSON and recreate social and enterprise connections as identity providers, port Actions or Rules logic, and switch application SDKs to standard OIDC. Teams without Keycloak operations experience often find the cluster and database work the steepest part. A fixed-scope engagement lets you decide which parts to keep in-house and which to hand off, with deliverables agreed in writing before work starts.
How long does an Auth0 to Keycloak migration take, and what does it depend on?
The duration depends on how much tenant configuration you have, how many applications and connections need rework, and how much of your login logic lives in Auth0 Actions or Rules. The number of users matters less than the number of integrations, although large user sets make the export and import steps slower to validate. Password hash delivery is outside your control, because Auth0 does not guarantee a delivery date for hash exports, so plan that step early. Keycloak's own guidance is that realm export and import has limitations as a backup mechanism and requires all nodes to be stopped while it runs, which affects cutover planning. Ask for a timeline that lists the dependencies separately: Auth0 support response, application testing, and the production change window.
What skills and staff time does running Keycloak require?
Running Keycloak in production needs people who can operate a Java-based identity server, a supported database, and the high availability design you choose. Keycloak supports PostgreSQL 14 to 18 among other databases, and both supported high availability designs need a synchronously replicated database, so your database team is part of the ownership model. You also need monitoring, which Keycloak exposes through metrics, plus a process for backups and restores that accounts for the export limitations. On Kubernetes, the Keycloak Operator is installed through Operator Lifecycle Manager and manages Keycloak and realm import resources. Staff time recurs for patching, reviewing upgrades and on-call response, so count those hours in the cost comparison alongside infrastructure.
Will our users keep their passwords when we move from Auth0?
Only if you obtain password hashes from Auth0 and Keycloak can import them, and the Auth0 step is the constraint. Auth0 does not include password hashes in standard user exports, so you must request the hash export through a support ticket on a paid plan, and the option is not available on the Free tier. Auth0 does not guarantee a delivery date, so start that request early. Once you have the hashes, your migration must confirm that the hashing algorithm and parameters map to a Keycloak credential type, which your engineers should test with sample accounts before cutover. If hashes cannot be moved, plan a password reset or a fallback flow for those users and tell them in advance.
How are Keycloak upgrades handled compared with a hosted Auth0 tenant?
With Keycloak you schedule and apply upgrades yourself, while Auth0 updates its hosted service on its own schedule. Keycloak has planned four minor releases a year since version 26.0, and the project says breaking changes in a minor release will be opt-in. Database schema migration runs automatically at startup by default, but the upgrading guide suggests manual migration for large deployments, so review that choice before each upgrade. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Build a test environment, run your applications against the new version, and record the upgrade procedure as part of your operating model.
Can Keycloak handle B2B tenants and per-customer login the way Auth0 Organizations does?
Keycloak can model B2B tenants through realms and its Organizations feature, but the design differs from Auth0's tenant and Organizations model. A realm is a separate isolation boundary with its own users, clients and identity providers, which suits strong separation between customers, while the Organizations feature groups members under a shared realm. Per-customer identity providers and domains are configured in Keycloak, and the token contents change, so applications must be tested against the new claims. Confirm your number of customers, whether each needs its own login connection, and how you will administer them, because these choices set the realm layout. Ask for a design review that maps each Auth0 Organization to its Keycloak equivalent before committing to a structure.
How DeployOpen helps evaluate, implement or migrate Keycloak
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For an Auth0 exit, that means the Keycloak cluster, its database, the realm design, the identity brokering to your social and enterprise providers, and the application client configuration all run where your security team already has control. Most engagements are fixed-scope, so the work is split into phases with deliverables and timelines agreed in writing before any work starts. An evaluation phase can test a realm model against your real Organizations, roles and login flows before you commit to a migration.
The decisions that usually need outside help are concrete: whether to run Keycloak as a single cluster or use the multi-cluster design, which supported production database to standardize on, whether schema migration runs automatically at startup or is applied manually, and how operator updates are approved. DeployOpen can plan and build these pieces, harden the deployment, set up backup and restore for realm data (keeping in mind that the export and import commands have documented limits as a backup method), and document the result. Ask any provider for a written scope that names each of these components, the acceptance tests for the cutover and who performs the password hash handling. Quotes follow from that written scope. DeployOpen does not publish a price list, so compare proposals on scope and deliverables, not on a headline figure.
Once the platform is live, the work does not stop. Keycloak plans four minor releases a year, so a retainer for upgrades, patch review and continuous testing keeps the cluster current without surprises. DeployOpen also runs security testing of the finished deployment, covering the applications and APIs that rely on the new login, the cloud and infrastructure underneath it, and the realm and client configuration. Testing results feed back into the hardening backlog. Note that DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Confirm with your assessor which evidence they expect from the identity platform before the scope is signed.
