Best European Alternatives to Auth0

Why people leave Auth0

Two things people repeat about Auth0 are worth checking before you start a migration. The first is that it locks your users into American data centres.

It does not: a region is picked when the tenant is created, EU and EU-2 sit in that list beside US, Canada, the UK, Australia and Japan, and the choice ends up inside the tenant domain.

The second is that the free plan is stingy. It covers 25,000 monthly active users, on the business ladder as well as the consumer one, and the self-hosted alternatives on this page have no user ceiling at all — so the free tier is not what this comparison turns on.

The reason teams leave is the shape of the invoice. Billing follows monthly active users, so the line item moves with traffic rather than with revenue, and the ladder you land on depends on who your users are.

At 500 monthly actives, Essentials is $35 a month for a consumer product and $150 for a business one; Professional is $240 against $800. Every extra enterprise SSO connection adds $100 a month, and the AI agents add-on multiplies the base by one and a half.

Read that together and the pattern is clear. Auth0 is inexpensive while your users are anonymous consumers and expensive the moment they are companies whose IT department wants SAML — which is the exact moment your product starts earning real money. The service has not changed. The customer has, and the price follows.

• The bill tracks logins, not value Monthly active user pricing means a marketing campaign, a seasonal peak or a wave of dormant accounts waking up all arrive as an invoice. Nothing about the service got better that month. Teams that self-host an identity server pay for a virtual machine and a database, and a hundred thousand logins costs what a thousand costs.
• Selling to businesses costs four times as much At the same 500 monthly active users, the business ladder is $150 a month where the consumer one is $35, and $800 where the consumer one is $240. On top of that, each additional enterprise SSO connection is $100 a month. Federating one more corporate directory is a configuration change in every alternative here and a recurring charge on Auth0.
• The region lives in the domain Pick EU when the tenant is created and the domain reflects it, following the same pattern as the documented example example-co.au.auth0.com. That is fine on day one and awkward later, because the issuer URL is what every application, mobile build and API token validator has been configured to trust. Residency is not a setting you flip in a console here; it is part of the identifier.
• The transfer rests on a political instrument Okta, Inc., described in its own privacy policy as including its subsidiary Auth0 LLC, sits at 100 First Street in San Francisco and certifies under the EU-U.S. Data Privacy Framework. A framework is an arrangement between administrations, and the previous two arrangements covering the same route were struck down by the Court of Justice. Choosing the EU region does not remove the American company from the chain.

What you have to replace, not just match

Auth0 is three products bolted together, and working out which one you actually depend on decides whether this is a week or a quarter.

The first is the hosted login page: a screen you never wrote, styled in a dashboard, handling sign-up, password reset, social buttons and MFA prompts. The second is the protocol server underneath it, issuing OAuth 2.0 and OpenID Connect tokens that your APIs validate. The third is the extensibility layer, where Actions run your own code inside the login pipeline and turn the identity provider into a place where business logic lives.

Every tool on this page replaces the second one properly. The first one is where the work is, because most alternatives expect you to build that screen. The third is the trap: if there are Actions enriching tokens, calling an internal service or blocking logins from certain domains, that code has to move somewhere and no alternative here has a drop-in equivalent.

The alternatives compared

How each alternative compares to Auth0

What actually breaks when you switch

The issuer URL is the thing that breaks, and it breaks everywhere at once. Every application, mobile build, API gateway and background job has been told to trust tokens from your Auth0 domain, and that domain carries the region in it.

Changing it is a coordinated release across every client you ship, including the mobile versions sitting on phones you do not control, which is why teams run both providers in parallel for a period rather than cutting over on a date.

Passwords and second factors are the next problem, and they are separate problems. Profile data exports cleanly enough as JSON or CSV, with the CSV capped at 30 fields and the file deleted after a day.

Password hashes are not in that export, so the realistic route is verifying against the old tenant on first login and writing a new hash locally. TOTP secrets and registered security keys do not move at all, so every user who enrolled a second factor enrols again.

Then there is the code nobody remembers writing. Actions that enrich a token with a role, call an internal billing service or reject sign-ups from consumer email domains are business rules living inside the login pipeline, and they are usually undocumented. Inventory them before you commit, because that list is the difference between a fortnight and a quarter.

If I can already pick the EU region, what is left to solve?

Cost, mostly, and the direction it moves in. The EU region answers where the records are kept, and answers it well enough that a procurement questionnaire about storage location is satisfied without changing anything. It does not touch the billing model, which is the thing that made you look.

The second thing left is the corporate chain. The contracting party is a Californian corporation that relies on the EU-U.S. Data Privacy Framework, so lawful transfer depends on an arrangement between governments rather than on a property of the software. Organisations that have watched two such arrangements fall over tend to treat that as a live risk rather than a settled one.

If neither the money nor the chain bothers you, the honest advice is to stay, turn on the EU region and spend the migration budget elsewhere.

What happens to my users’ passwords when I move?

This is the question that decides the project plan. The documented bulk export produces user profile data in JSON or CSV, with CSV capped at 30 fields and the generated file removed after a day. Password hashes are not part of that export.

The standard answer is a lazy migration: stand the new identity server up beside Auth0, and the first time a user signs in, verify the password against the old system, write a fresh hash into the new one, and stop asking the old system about that account. After a few months the tail is small enough to reset by email.

The alternative is a forced reset for everybody on a single date, which works and costs you a measurable slice of your user base. Pick deliberately, because this is where identity migrations quietly lose customers.

Will I have to build the login screen myself?

With Ory and, to a lesser degree, Keycloak, yes. Auth0 hands you a hosted page that already covers sign-up, reset, social providers and the MFA prompt, and it is genuinely the part people underestimate when they compare feature lists.

Keycloak ships its own login pages with a theming system, so the screen exists and you are restyling rather than writing it. Zitadel likewise has hosted login flows with branding per organisation. Ory deliberately does not: Kratos gives you the flows and expects your front end to render them.

Cost this in weeks, not in story points. Sign-up, forgotten password, email verification, MFA enrolment, MFA challenge, account linking and the error states of each is a fortnight of front-end work that nobody put on the migration plan.

Do any of these handle Actions and the login pipeline?

Not as a like-for-like replacement, and anyone claiming otherwise is glossing. Actions let you run JavaScript at defined points in the login pipeline, in Auth0’s runtime, deployed from Auth0’s dashboard.

Keycloak’s answer is authenticator SPIs and custom providers: real extension points, but Java, compiled, and deployed with the server rather than edited in a browser. Ory’s answer is webhooks fired at flow transitions, which means your code runs in your own service. Zitadel takes a comparable path with actions and event triggers.

Functionally you can reach the same outcome. Operationally you have turned a snippet in a dashboard into a deployable artefact with its own pipeline, which is better engineering and more work.

Which one to pick

If your Auth0 tenant is the login for your own product and you liked Auth0 for being a developer tool rather than an IT system, Ory is the honest first choice even though it sits second on this page. It is the one that will feel familiar, and the front-end work it demands is the price of that familiarity.

If the expensive part is having business customers — organisations, enterprise connections, a corporate directory per account — Zitadel addresses precisely that, and it does so without the step change in price that made you start reading.

If the objection is the meter itself, Keycloak ends it. Logins stop being a billable event, federation stops being a subscription, and what you pay for instead is a server and the person who looks after it.

And if none of that is your situation, the fair conclusion is to stay. Select the EU region, take the 25,000 free monthly actives, and revisit when your first enterprise customer asks for SAML.