Auth0 vs Ory: when a headless, self-hosted stack fits your team
A developer team that wants to own the login screens and run identity inside its own infrastructure is the reader this section serves. Ory Kratos and Ory Hydra fit when your engineers build their own login and account UI and can operate the servers themselves. Kratos handles identities, passwords, passkeys, social sign-in and MFA such as TOTP through API calls, and Hydra provides an OpenID Certified OAuth 2.0 server and OpenID Connect provider that works alongside your user store through headless APIs. Auth0 fits better when you would rather buy a hosted, feature-complete product with its own login pages, dashboards and managed operations, and when the team does not want to build and maintain screens for password reset, verification and account recovery.
Before choosing, confirm what the Ory open-source servers do not include. Per the Ory Kratos README, SCIM, SAML, organization login (SSO) and CAPTCHAs are enterprise features outside the open-source version. Multi-tenancy and organizations sit in the Ory Enterprise License as well. Ask Ory for the current feature matrix in writing, and map each control your auditors or enterprise customers will ask about to either the open-source servers or a commercial license. Also check how your team will handle upgrades: Ory states that open source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required.
The decision turns on two questions. First, do you need SAML, SCIM, organization SSO or multi-tenancy at launch? If yes, budget for the Ory Enterprise License or plan a different stack, and compare the license terms with the Ory Enterprise License documentation before you commit. Second, will your organization accept the Enterprise License terms, or will it run open source with no guaranteed CVE patching and planned downtime for upgrades? Answer both questions before you estimate engineering effort, because the login UI, operations and security patching work is where most of the ongoing cost sits.
Which option fits which team situation
A team building a new product usually wants the login screens, onboarding and account recovery to match its own design system. Ory fits this case well because Ory Kratos is an API-first identity and user management system that leaves the login UI to the application team, and Ory Hydra provides a hardened, OpenID Certified OAuth 2.0 server and OpenID Connect provider that works with that user store through headless APIs. Auth0 fits when the team would rather buy hosted login pages, universal login and a managed Actions model than write and maintain the UI itself.
- Ory is the better fit when the front-end team owns every screen, flow and error state and has the engineering capacity to maintain them.
- Auth0 is the better fit when speed to a working login matters more than owning the screens, and the team accepts hosted pages.
- Passkeys and MFA: Kratos supports passkeys and TOTP, but the team builds the enrollment and recovery screens itself.
- Token and API control: Hydra gives direct control over OAuth 2.0 flows, which suits teams that expect to issue their own API tokens.
- Check before deciding: confirm which passkey and MFA flows each product covers in the versions you plan to run.
When enterprise customers require SAML single sign-on, SCIM provisioning or organization-level SSO, the open-source question changes. The Ory Kratos README states that SCIM, SAML, organization login (SSO) and CAPTCHAs are enterprise features not available in the open-source version. Those capabilities come with the Ory Enterprise License, so Ory is a fit for this situation only when the budget and procurement process include that license. Auth0 covers enterprise connections as part of its commercial plans, which can be simpler for B2B sales-led products but adds recurring cost as connections grow.
- Ory with the license is the better fit when the product needs self-hosted SAML and SCIM and the company accepts a commercial license for them.
- Auth0 is the better fit when the team needs enterprise connections quickly and prefers to buy them as a managed service.
- Open-source gap: the open-source Kratos and Hydra servers do not provide SAML or SCIM on their own, so plan a separate component or license.
- Multi-tenancy: Kratos multi-tenancy and organizations are part of the Ory Enterprise License, not the open-source servers.
- Confirm with the vendor: ask Ory which connection types and SCIM features are included in the license you quote.
Organizations in banking, healthcare or the public sector often must keep identity records, logs and support access inside a defined jurisdiction or their own data center. Ory's open-source components, Kratos, Hydra, Keto, Oathkeeper and Polis, are Apache-2.0 licensed and can run on infrastructure the organization controls, with Kratos supporting PostgreSQL, MySQL and CockroachDB as its database. Auth0 offers regional tenants and a Private Cloud option, but the data still sits with a hosted provider, so the residency analysis depends on the contract and the region chosen.
- Ory is the better fit when the rule requires that identity data never leave the organization's own servers or an approved provider.
- Auth0 is the better fit when a regional hosted tenant meets the residency and transfer rules the legal team has already accepted.
- Database choice: Kratos can run on PostgreSQL, MySQL or CockroachDB, which allows the team to fit existing database controls.
- Operational evidence: the organization must produce its own backup, access and change records, since no vendor carries them.
- Ask Auth0 in writing: where support staff access tenant data, where logs are stored and which sub-processors are involved.
A small team with few platform engineers faces a different cost. Self-hosting Ory means operating the databases, upgrades, backups and monitoring of several services, and building the login UI. The Ory documentation says Ory Open Source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Auth0 removes the operational load but charges by monthly active users, so the trade-off shifts as the user base grows.
- Auth0 is the better fit when no one on the team can own an identity system's uptime, patching and incident response.
- Ory is the better fit when the team has a platform engineer who can run the stack and the product needs control over the data and flows.
- Open-source limits: without the Enterprise License, there are no guaranteed CVE patch timelines, so plan an internal patch process.
- Ongoing work: upgrades, database maintenance and backups recur for as long as the system runs.
- Ask for a quote: request a written scope covering setup, the login UI, support hours and upgrade support before choosing Ory.
Which scenarios favor Ory and which favor Auth0
This table compares the scenarios where Ory's open-source servers or Auth0's managed platform fit better, based on the capabilities and licensing limits covered on this page. Read each row against your own requirements, and check the enterprise feature boundary before you commit to Ory's open-source servers for B2B or workforce use.
| Scenario | Better fit | Why |
|---|---|---|
| Custom login UI built by your own developers | Ory | Kratos is API-first and leaves the login UI to your team, so you control every screen and flow. |
| Passkeys and MFA with TOTP in your own login flows | Ory | Kratos supports passkeys and TOTP as open-source features, so you can build the enrollment and recovery journeys yourself. |
| Standards-based OAuth 2.0 and OIDC server | Ory | Hydra is an OpenID Certified OAuth 2.0 server and OIDC provider that works with your existing user system through headless APIs. |
| SAML or SCIM provisioning required from day one | Auth0 | SAML, SCIM and organization SSO are Ory Enterprise License features, not part of the open-source Kratos server, so confirm licensing before choosing Ory. |
| Multi-tenant B2B with per-customer organizations | Auth0 | Kratos multi-tenancy and organizations are Ory Enterprise License features, while Auth0 Organizations are part of its managed platform. |
| Data residency under your own control | Ory | Self-hosted Kratos and Hydra run in your own cloud account or data center, keeping identity records where your policy requires. |
| Limited in-house platform and security engineering | Auth0 | Ory open source leaves upgrades, CVE patching and operations to your team, and Ory states open source suits cases where upgrade downtime is acceptable and guaranteed CVE patching is not required. |
| Strong in-house operations and an OEL support need | Ory | Teams with operating capacity can run open source, or add the Ory Enterprise License for SLAs and timely CVE patches, and confirm its terms with Ory. |
Where customer identity data lives under each option
Customer identity data includes profiles, password hashes, sessions, logs and support access, and each option places these in a different party's hands. The cards below set out where that data sits under Auth0, self-hosted Ory, Ory Network and the Ory Enterprise License, and which obligations stay with your team in each case.
Auth0 hosted tenant location
Your users, tenant configuration and logs live in an Auth0 tenant that Okta operates. Confirm with Auth0 which region hosts your tenant, whether a Private Cloud or regional deployment is available on your plan, and where support staff can access data. Ask for the current data processing terms in writing, since you have limited say over the physical location of a multi-tenant SaaS service.
Self-hosted Ory in your infrastructure
With Apache-2.0 Ory Kratos and Ory Hydra, identity records sit in the database you provision, such as PostgreSQL or MySQL, inside your cloud account or data center. You choose the region, network boundaries, backup location and key management. The trade-off is that you own the database, the encryption, the access controls and the operational runbooks that Auth0 otherwise carries for you.
Ory Network as managed cloud
Ory Network is Ory's managed cloud service, sitting alongside the self-hosted components. Choosing it moves hosting, and therefore data location and operator access, back to a third party, so it is a different residency decision from self-hosting. Ask Ory where Network tenants are hosted, which sub-processors handle identity data, and how the contract allocates support access.
Logs and support access
Authentication logs, audit events and error traces can contain identifiers and IP addresses even when passwords are protected. In a self-hosted Ory deployment you decide where these logs are shipped, how long they are kept and who can read them. On Auth0, ask how long tenant logs are retained on your plan and who at Okta can access them during a support case, and record the answer in your data inventory.
Compliance evidence your team produces
Under Auth0, much of the control evidence is produced by the vendor and reviewed in its assessments. Under self-hosted Ory, your team must produce evidence for access reviews, change records, backup restore tests, encryption settings and logging configuration. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any opinion on them.
CVE patching responsibility
Ory states that Ory Open Source suits evaluation and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. The Ory Enterprise License adds timely CVE patches and 24/7 support SLAs on top of the same servers. If your policy requires a defined patch window, you either fund that license or assign an internal owner to track releases and apply fixes yourself.
What the Apache-2.0 servers include and what Ory Enterprise License adds
The core Ory servers are Apache-2.0: Kratos for identities, Hydra for OAuth 2.0 and OpenID Connect, Keto for permissions, Oathkeeper for the identity and access proxy, and Polis for SAML and OIDC single sign-on with SCIM directory sync. Kratos and Hydra v26.2.0 were both published on March 20, 2026, so confirm the release you plan to deploy against the current tags in the Ory Kratos repository and the Ory Hydra repository. Within the open source set, Kratos covers passwords, passwordless codes, passkeys, social sign-in and TOTP-based MFA, and Hydra provides the OpenID Certified OAuth 2.0 server. Ory Polis is also Apache-2.0 and covers the SAML and SCIM requirements that the Kratos README places in its enterprise list, so ask your architects to test Polis against your identity provider and directory before assuming a paid tier is needed for those two protocols.
The Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features outside the open source version. The Ory Enterprise License adds optimized builds of the same servers, with Kratos multi-tenancy and organizations, the Hydra ROPC grant, 24/7 support SLAs and timely CVE patches. Ory states that OEL builds are drop-in replacements for open source installations, which lowers the cost of moving later, but the license, support and patch commitments are separate purchases. The Ory documentation on the Ory Enterprise License describes the current terms. Ask Ory to put the feature list, patch timelines and support hours into a written quote, and ask which of them apply to your deployment model.
Ory itself says open source fits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. For a regulated customer identity service, that boundary is the decision point. If your team will apply security updates within its own change window and accepts that tenant-level isolation is built by your engineers, the open source servers may be sufficient. If your audit or contract requires vendor-backed patch commitments, or your customers need organization-level login, plan for the OEL from the start and confirm the multi-tenancy model against your B2B requirements before design work begins.
What moving from Auth0 to Ory involves at a high level
The sequence turns Auth0 tenant contents into Ory Kratos identities, Ory Hydra OAuth clients and a login UI you own, and ends with a tested cutover. Each step closes with a check, so the team knows what is ready before the next one starts.
Inventory applications, connections and Actions
Someone on the identity team lists every Auth0 application, API, social and enterprise connection, Action, Rule and Organization, along with the login and token behavior each one drives. Application owners confirm which flows must survive the move. Auth0 Organizations and Actions have no direct one-to-one copy in Ory, so each one is marked for rebuilding in Kratos flows, Hydra consent logic or your own services. The inventory is complete when every application has an owner and every connection has a target: Kratos, Hydra, an external identity provider or retirement.
Run the Auth0 bulk user export
An administrator starts the users export job in the Dashboard or through the Management API (POST /jobs/users-exports), choosing NDJSON or CSV. The export carries profile data, identifiers and metadata but does not include password hashes in standard exports. The team stores the file in an encrypted location with access logging, because it holds personal data. The step is done when the record count matches the tenant's user count and a sample of records has been checked against the Dashboard.
Request password hash exports by support ticket
On a paid Auth0 plan, the team opens a support ticket asking for password hash exports. Auth0 does not guarantee a delivery date, and the option is not available on the Free tier, so the request should go in early and the team should plan for users who must reset passwords if hashes never arrive. The team confirms the hash algorithm and format in the delivered file before any other step depends on it. The step closes when the hashes are in hand and their format is documented.
Confirm Kratos can verify the imported hashes
An engineer loads a test set of exported hashes into a non-production Kratos instance and attempts a password login for known test accounts. The check confirms that Kratos supports the hash algorithm Auth0 used and that the login succeeds without a reset. Where a hash format is not supported, the team decides between forced password resets for those users and a custom import path. The step is done when test logins succeed for each hash type in the export, and the results are written down.
Build the login UI and self-service flows
Because Kratos is API-first, the team builds its own login, registration, recovery, verification and MFA screens, and configures passkeys, TOTP and social sign-in as the policy requires. Front-end and security engineers own this work, and the result is a UI that calls Kratos flow APIs. The step is complete when a tester can complete every login path in staging, including account recovery, MFA enrollment and passkey registration, and the security team has reviewed the flows.
Move OAuth clients to Hydra
The team registers each Auth0 application as an OAuth 2.0 client in Hydra, mapping grant types, redirect URIs, scopes and token lifetimes from the inventory. Hydra's consent and login flows are wired to the Kratos-backed login UI, and each application's SDK is switched to standard OpenID Connect. Auth0 Rules and Actions that changed tokens are reproduced in the login service or in claims logic the team controls. The step closes when each client completes an authorization code flow against staging and the issued tokens match the claims the application expects.
Decide how SAML and SCIM are sourced
The team decides whether enterprise SAML, SCIM directory sync and organization-level SSO will come from Ory Enterprise License features, from Ory Polis for SAML and OIDC single sign-on with SCIM sync, or from a different platform. The open-source Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features, so this decision carries license cost and support terms. Procurement should ask Ory to confirm current feature availability in writing. The decision is recorded when each enterprise connection has a named source and an owner.
Run a parallel period and cut over
For a defined period, selected applications run against Ory while Auth0 stays active for the rest, and the team compares login success rates, token contents and support tickets. Users are moved in groups, with rollback steps written for each group, and DNS, certificates and redirect URIs are changed in a planned window. Auth0 is kept in read-only state for a period agreed with the business, then retired after the team confirms no application still calls it. The step is complete when every application authenticates through Ory and the retained Auth0 export is archived under the organization's retention policy.
Questions buyers ask before choosing Ory or Auth0
How much effort does a Kratos and Hydra deployment take?
Expect more engineering work than a hosted tenant, because Ory ships headless servers rather than a finished login experience. Kratos handles identities, credentials and recovery flows, and Hydra issues OAuth 2.0 and OpenID Connect tokens, so your team deploys both, connects them to a PostgreSQL, MySQL or CockroachDB database, and wires them to your applications. Kratos also supports SQLite, but that choice is for evaluation rather than production. The effort scales with the number of login flows, the number of applications and the operational runbooks for upgrades, backups and high availability. Ask any implementation partner for a written scope that lists each component, environment and handover item before work starts.
Can our team build the login UI ourselves?
Yes, and that is the intended model. Kratos is API-first and lets teams build their own login UI for passwords, passwordless codes, passkeys, social sign-in and TOTP multi-factor authentication. Auth0 provides a hosted login page and customization options that Ory does not, so you take on design, accessibility testing, error handling, account recovery screens and security review of the front end. Confirm whether your front-end and identity skills cover those tasks, or whether you need a partner to build and test the flows under a fixed scope.
What do SAML and SCIM require from an Ory deployment?
The open-source Kratos server does not provide SAML, SCIM, organization login (SSO) or CAPTCHA. The Kratos README lists these as enterprise features offered on top of self-hosted Kratos under the Ory Enterprise License. Ory Polis, which is Apache-2.0, covers SAML and OIDC single sign-on with SCIM directory sync, so confirm with Ory how Polis fits your architecture and licensing before you assume it covers your use case. If your applications need SAML service provider support or automated provisioning from a corporate directory, price those requirements into the decision from the start. Ask for written confirmation of which components and features are included in your chosen license.
How do password hashes move from Auth0 to Ory?
Auth0 does not include password hashes in standard user exports. On paid plans, you request the password hash export through a support ticket, and Auth0 does not guarantee a delivery date. The option is not available on the Free tier. Standard bulk exports in NDJSON or CSV through the Dashboard or the Management API cover profiles and metadata, so plan for the hash request as a separate workstream with its own lead time. Once you receive hashes, confirm that Kratos can verify the hash algorithm you were given, because an unsupported algorithm forces a password reset for those users. Ask Auth0 which format the export uses before you commit to a cutover date.
What cost drivers differ between Auth0 and Ory?
Auth0 charges by plan and by usage tiers, so its cost tracks your user growth and the enterprise features you enable. Ory Open Source has no license fee, so your costs shift to infrastructure, database operations, engineering time, monitoring and any support contract. Ory Enterprise License and Ory Network add licensed or managed costs with quotes set by Ory. Your cost model should list each component: hosting, database high availability, backups, upgrades, login UI development, security testing and on-call support. Ask Ory for its licensing terms in writing and request a quote from your partner based on a written scope, not on a list price.
Is Ory Open Source safe for production without CVE SLAs?
Ory says Ory Open Source fits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. That means production use depends on your risk tolerance and your ability to patch quickly yourself. The Ory Enterprise License adds timely CVE patches and 24/7 support SLAs, and Ory states that OEL builds are drop-in replacements for open source installations. If your regulator or customers expect contractual patch timelines, treat the Enterprise License as a requirement rather than an option. Confirm the patch process with Ory and assign an owner for monitoring security advisories.
What does the work need from our staff?
Plan for identity engineers who can operate Kratos and Hydra, database administrators for PostgreSQL or another supported database, front-end developers for the login UI, and a security owner who reviews flows, secrets and access. Operations staff need to handle upgrades, backups, monitoring and incident response on a regular schedule. Application developers must move each app to standard OIDC flows. Staff time is usually the largest recurring cost, so ask any partner to name the roles, the hours they expect each role to contribute and the handover material they will leave behind.
Questions to settle before you pick one
Start by fixing the requirements that decide the shortlist. Ask Ory which protocols you need to serve: Ory Hydra is an OpenID Certified OAuth 2.0 server and OpenID Connect provider, but SAML is listed among the Ory Enterprise License features, so a SAML requirement from a customer or partner moves the decision into the commercial tier. Ask Auth0 the same question for your current tenant and plan, including whether any application depends on Actions, custom database connections or the Organizations feature. Then list every enterprise connection you rely on today (SAML, OIDC, directory sync) and record whether each one is a feature you would have to buy from Ory. For multi-tenant B2B use, confirm with Ory whether Kratos multi-tenancy and organizations are included in your intended edition, because the open-source servers do not provide them.
Next, settle the operating model. Confirm the tenant or customer isolation model you need, where identity data and logs must physically reside, and who can access them during support. Ask Ory for its patch commitment in writing: the Ory Enterprise License offers 24/7 support SLAs and timely CVE patches, and Ory states that open-source deployments are fine where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Decide which of those two conditions your security policy accepts. Also inventory the skills in your own team. Running Kratos and Hydra means operating two services, a database, key rotation, upgrades and a login UI you build yourself, and that work recurs after launch.
Finally, run a proof of concept on one application before you commit. Pick an application with a realistic mix of local passwords, passkeys and an enterprise connection, then export a sample of users from Auth0 using the bulk user export job and check which password hashes you can actually verify on Ory. Measure how long it takes your team to build the login screens and the account recovery flow, and test a complete token exchange with your application's SDK. Record the open questions as written answers from Ory and Auth0, and use that record as the basis for a fixed-scope quote. Treat the proof of concept as the evidence for the decision, not the vendor's documentation.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For teams weighing Ory against Auth0, we work from a written scope that settles which parts of Ory your login flows need, including whether the Enterprise License features are required.
How we scope
- We map your login flows, passkey and MFA requirements, and token consumers against Ory Kratos and Hydra before work starts.
- We identify which needs fall under Ory Enterprise License features such as SAML, SCIM, organization SSO and multi-tenancy.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.
How we build
- We deploy Kratos and Hydra in your cloud account, data center or air-gapped network, with the database backend you choose.
- We build the login and registration UI that Ory leaves to the application team, and wire it to Hydra's OAuth 2.0 and OpenID Connect flows.
- We test passkey enrollment, TOTP recovery, token lifetimes and session revocation, then harden the deployment and document the results.
How we hand over
- You receive architecture records, configuration documentation, runbooks for upgrades and backups, and the test evidence from the build.
- We plan a cutover for user data and password hashes, including checks that imported hashes verify before any user is moved.
- Your team is trained on operating the stack, rotating keys, and reviewing the security settings that matter for audit readiness.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking Ory releases, applying patches, and deciding when a self-hosted upgrade needs a maintenance window.
- We can help you prepare identity controls and evidence for compliance assessments, while independent auditors issue any audit reports.
