Timonier vs Auth0

You run Auth0 today, and someone has asked where your users' identity data actually lives and under whose legal reach: legal, security, or a customer's due-diligence questionnaire.

The jurisdiction question

Auth0's parent, Okta, Inc., is a Delaware-incorporated company headquartered in San Francisco. Under 18 U.S.C. § 2713, a covered US provider must produce data in its possession, custody, or control regardless of where that data is stored. 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 offers EU-region public cloud and a private-cloud option in Germany, Ireland, the UK, and France, so "your data leaves the EU with Auth0" isn't something we can say, and isn't true as a blanket claim. And this is an infrastructure-jurisdiction argument only: it says nothing about where Timonier itself is incorporated. Schrems II is a separate legal question. It's about whether a data transfer to a third country has an adequate legal basis, not about a provider's exposure to compulsory production, and the two shouldn't be read as one argument. Standard contractual clauses and data processing agreements are a further, separate mechanism and aren't addressed here.

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.

Past the protocol layer, treat the following as separate line items in a migration plan, not something that carries over automatically:

• Organizations. Auth0 ships an Organizations feature for B2B multi-tenancy. We have no equivalent construct.
• Custom logic and claims injection. Auth0's Rules are end-of-life on 2026-11-18; 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, but it also maintains its own SSO session cookie outside that flow. 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 a distinct surface, separate from its standards-based Authentication API. Our closest analogue is a narrower set of admin routes: list, ban, import, and metrics on users, not a general-purpose management API.
• Social federation. We don't federate sign-in to third-party identity providers. That's a decision, not a gap still being filled.
• Password hashes. This one isn't specific to where you're going: Auth0's own export tooling does not export the password hashes of Auth0-hosted database-connection users. Any destination hits the same wall.

None of this is "largely OIDC." The protocol layer is a straight swap; Organizations, Actions-based claims injection, logout semantics, Management API breadth, social federation, and the user records underneath it all are separate, per-integration migration decisions.