An Auth0 alternative: jurisdiction and what migrates

You run Auth0 today. Then someone asks where your users' identity data lives, and whose law can reach it. It might be your legal team or your security lead. Often it's a line in a customer's due-diligence questionnaire, and somebody has to fill it in.

Before going further, the reasons to stop reading. We don't do SAML. We don't store passwords. We don't offer social login ("Sign in with Google" and the like), and that won't change. We hold no certifications today. If you need any of those from us, this page won't change the answer.

The jurisdiction question

Auth0 is a product of Okta, Inc., a Delaware-incorporated company headquartered in San Francisco. Under 18 U.S.C. § 2713, a provider of electronic communication service or remote computing service must preserve or disclose data in its possession, custody, or control, regardless of whether that data is located within or outside of the United States. That exposure attaches to the provider entity, not to the hosting region. The EDPB and EDPS's 2019 joint assessment of the US CLOUD Act reaches the same conclusion: it applies to providers who fall under US jurisdiction, irrespective of where the data is stored. Whether Auth0 meets that provider classification for any given dataset is a legal question this page does not resolve, and we do not assert that it does.

Two things this argument does not say. Auth0 documents public cloud regions across EMEA and a Private Cloud on Azure deployable in Germany, Switzerland and the United Kingdom, among other regions, so "your data leaves the EU with Auth0" isn't something we can say. And this page doesn't address Schrems II, standard contractual clauses or data processing agreements.

What actually migrates: the protocol layer

Strip out the vendor-specific tooling and the sign-in protocol layer is OIDC on both sides. Auth0 publishes OIDC discovery at the standard well-known endpoint; we do the same, with discovery, JWKS, and the openid, profile, and email scopes over the authorization-code flow. That's the part of a migration that's genuinely mechanical: point a generic OIDC client at a new issuer, with a new client ID and secret. Check two things first. Our ID tokens are signed with EdDSA only, and public clients can register loopback redirect URIs only.

Everything past the protocol layer needs its own line in your migration plan. None of it comes across by itself.

• Organizations. Auth0 ships an Organizations feature for B2B multi-tenancy. We have no equivalent construct.
• Custom logic and claims injection. Auth0 states that Rules and Hooks reach end of life on November 18, 2026. Actions (Node.js) is the successor, and it's also how Auth0 recommends injecting namespaced custom claims into tokens. That's a convention of theirs, not a requirement of the OIDC spec itself. We have no equivalent hook for injecting custom claims.
• Logout. Auth0 implements OIDC RP-Initiated Logout 1.0, and it also keeps its own session, in an SSO cookie, separate from your application's session. We have one top-level logout route rather than a per-app one, and no end_session_endpoint in our discovery document. Logout semantics aren't a drop-in match in either direction.
• The management surface. Auth0's Management API is separate from its Authentication API. Our closest analogue is a narrower set of admin routes for users and sessions (list, ban and unban, delete, import, session revocation, metrics), not a general-purpose management API.
• Social federation. We don't federate sign-in to third-party identity providers, so there's no "Sign in with Google" button to carry over. We decided that on purpose, and the reasoning is here.
• Password hashes. Auth0's own export tooling does not export the password hashes of Auth0-hosted database-connection users. Auth0 does release them as a PGP-encrypted export through a support case. We'd have nowhere to put them: our users table has no password column, so imported users go passwordless on their next sign-in.
• TOTP enrolments. Users who had a second factor set it up again.

So the protocol layer is a straight swap, and the rest is per-integration work. Organizations, claims injected by Actions, logout, Management API calls, social federation and the user records underneath them each get their own decision. That's why we won't call this migration "largely OIDC."

Our price is one flat monthly figure for the whole platform.