Open-source alternatives to Auth0: 7 identity and access management tools compared
Every one of these puts your user records and sessions on infrastructure you control, and what that costs is a service somebody has to run, patch and back up, which is the part teams underestimate when they weigh an Auth0 migration. keycloak/keycloak is the one most readers should look at first, because it speaks the standard protocols almost every application already supports.
What Auth0 does, and why people look elsewhere
Auth0 is a hosted identity service: login pages, social and enterprise single sign-on, multi-factor authentication and user management behind OAuth 2.0 and OpenID Connect.
- pricing by monthly active users
- user records and sessions live with the vendor
- an identity provider that must run inside your own network is not an option
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install | Best for |
|---|---|---|---|---|---|---|
| keycloak/keycloak | Apache-2.0Permissive: commercial use allowed | Commits in the last dayLast push October 11, 2026 | Java | 37,292 | See analysis | You want an identity server your applications talk to over standard protocols rather than a login page you have to build and maintain. The README describes user federation, strong authentication, user management and fine-grained authorization, and the run paths are a downloaded distribution or a Docker image, with separate client libraries, quickstarts and a Node.js adapter in companion repositories. |
| zitadel/zitadel | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last six monthsLast push October 9, 2026 | Go | 15,279 | Command documented | You are building a SaaS or B2B platform where multi-tenancy is the central problem. The README describes SSO, MFA, passkeys, OIDC, SAML and SCIM, a strict hierarchy of Identity System, Organizations and Projects with isolated data and policy scoping, an API-first surface over connectRPC, gRPC and HTTP JSON, and an event stream where every mutation is written as an immutable event for an audit trail. |
| goauthentik/authentik | Custom licenceCustom licence: read the LICENSE file | Commits in the last dayLast push October 11, 2026 | Python | 25,919 | See analysis | You already run containers or Kubernetes and need SAML, OAuth2 and OIDC, LDAP and RADIUS behind one login under your own control. The README describes it as an identity provider for modern SSO designed for self-hosting from small labs to large production clusters, with Docker Compose for small setups and a Helm chart for larger ones. |
| authelia/authelia | Apache-2.0Permissive: commercial use allowed | Commits in the last six monthsLast push October 11, 2026 | Go | 29,236 | See analysis | You already run nginx, Traefik, Caddy, Skipper, Envoy or HAProxy in front of internal applications and want one login plus a second factor without rewriting those applications. The README describes it as a companion for reverse proxies that allows, denies or redirects requests, with rules matching subdomain, user, group membership, request URI, request method and network. |
| logto-io/logto | MPL-2.0Weak copyleft: changes to its own files stay open | Commits in the last six monthsLast push October 11, 2026 | TypeScript | 14,667 | Command documented | You are building a multi-tenant SaaS or an agent platform and want OIDC, OAuth 2.1 and SAML behind a pre-built sign-in UI instead of assembling them. The README describes multi-tenancy, enterprise SSO and RBAC, pre-built sign-in flows, SDKs for more than 30 frameworks, connectors to other identity providers, and support for Model Context Protocol and agent-based architectures. |
| ory/kratos | Apache-2.0Permissive: commercial use allowed | Commits in the last six monthsLast push July 29, 2026 | Go | 13,907 | Command documented | You want identity flows as HTTP APIs your own front end calls, so no login logic lives in your application code. The README describes self-service login and registration, account verification and recovery, multi-factor authentication, profile and account management, identity schemas and traits, and admin APIs for lifecycle management, with installs on Linux, macOS, Windows and Docker against PostgreSQL, MySQL or CockroachDB. |
| supertokens/supertokens-core | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 6, 2026 | Java | 15,345 | See analysis | You want login and session logic to live in your own infrastructure next to a database you already run, without adopting OAuth protocol complexity in your application. The README describes three building blocks, a frontend SDK that manages session tokens and renders login widgets, a backend SDK with the sign-up and sign-in APIs, and this Java HTTP service, plus passwordless, social, email and phone login, session management, multi-factor authentication and user roles. |
Each alternative in detail
keycloak/keycloakOpen Source Identity and Access Management For Modern Applications and Services
- Best for
- You want an identity server your applications talk to over standard protocols rather than a login page you have to build and maintain. The README describes user federation, strong authentication, user management and fine-grained authorization, and the run paths are a downloaded distribution or a Docker image, with separate client libraries, quickstarts and a Node.js adapter in companion repositories.
- What you give up
- It is a Java and Quarkus service you have to keep running, and our analysis of Keycloak is direct that it is the wrong choice for a project that needs a fully managed, zero-maintenance identity service, because self-hosting means owning upgrades, backups and disaster recovery. Before deploying to production it also asks you to review the upgrade notes for your target version in RELEASES.md and to decide whether the built-in database or an external one fits your environment.
zitadel/zitadelZITADEL - Identity infrastructure, simplified for you.
- Best for
- You are building a SaaS or B2B platform where multi-tenancy is the central problem. The README describes SSO, MFA, passkeys, OIDC, SAML and SCIM, a strict hierarchy of Identity System, Organizations and Projects with isolated data and policy scoping, an API-first surface over connectRPC, gRPC and HTTP JSON, and an event stream where every mutation is written as an immutable event for an audit trail.
- What you give up
- AGPL-3.0 is the condition that shapes who can adopt it, and our analysis of ZITADEL says not to use it if your product is closed source and you cannot live with that. It also runs PostgreSQL and a Go service, so there is an operational surface even for a single-tenant login. Before committing, read LICENSING.md to see whether your distribution model is covered and confirm the Actions v2 webhook model can express the hooks you rely on today.
- First install step
- Full setup guide
curl -LO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml \ && curl -LO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example \ && cp .env.example .env \ && docker compose up -d --wait
goauthentik/authentikThe authentication glue you need.
- Best for
- You already run containers or Kubernetes and need SAML, OAuth2 and OIDC, LDAP and RADIUS behind one login under your own control. The README describes it as an identity provider for modern SSO designed for self-hosting from small labs to large production clusters, with Docker Compose for small setups and a Helm chart for larger ones.
- What you give up
- Our analysis of authentik says not to adopt it if nobody on the team can operate PostgreSQL and a reverse proxy, and that the reverse proxy has to pass the required headers, which is a real integration task rather than a checkbox. The licensing is the other thing: the repository links three licence files, including one at authentik/enterprise/LICENSE, so you should read that file rather than assume one licence covers the repository.
authelia/autheliaThe Single Sign-On Multi-Factor portal for web apps, now OpenID Certified™
- Best for
- You already run nginx, Traefik, Caddy, Skipper, Envoy or HAProxy in front of internal applications and want one login plus a second factor without rewriting those applications. The README describes it as a companion for reverse proxies that allows, denies or redirects requests, with rules matching subdomain, user, group membership, request URI, request method and network.
- What you give up
- It is not a general identity platform for external customers, and our analysis of Authelia is explicit that it will not manage your users for you, which is what most people looking at an Auth0 replacement actually need. Its OpenID Connect provider is also still listed as a beta on the roadmap despite the OpenID certification, and high availability needs a remote database and Redis rather than a local file.
logto-io/logto🧑🚀 Authentication and authorization infrastructure for SaaS and AI apps, built on OIDC and OAuth 2.1 with multi-tenancy, SSO, and RBAC.
- Best for
- You are building a multi-tenant SaaS or an agent platform and want OIDC, OAuth 2.1 and SAML behind a pre-built sign-in UI instead of assembling them. The README describes multi-tenancy, enterprise SSO and RBAC, pre-built sign-in flows, SDKs for more than 30 frameworks, connectors to other identity providers, and support for Model Context Protocol and agent-based architectures.
- What you give up
- There is no path with no database. Our analysis of Logto describes the open source path as always leaving the database, backups and upgrades with you, and PostgreSQL is required for the npm route. There is also a security setting to verify against your own endpoints: SSRF_ALLOWED_ADDRESSES and SSRF_PROTECTION_DISABLED, because a webhook or relying-party address on a private network changes how that behaviour should be set.
- First install step
- Full setup guide
curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | \ docker compose -p logto -f - up
ory/kratosHeadless cloud-native authentication and identity management written in Go. Scales to a billion+ users. Replace Homegrown, Auth0, Okta, Firebase with better UX and DX. Passkeys, Social Sign In, OIDC, Magic Link, Multi-Factor Auth, SMS, SAML, TOTP, and more. Runs everywhere, runs best on Ory Network.
- Best for
- You want identity flows as HTTP APIs your own front end calls, so no login logic lives in your application code. The README describes self-service login and registration, account verification and recovery, multi-factor authentication, profile and account management, identity schemas and traits, and admin APIs for lifecycle management, with installs on Linux, macOS, Windows and Docker against PostgreSQL, MySQL or CockroachDB.
- What you give up
- The README positions the open source distribution for individuals, researchers, experiments, prototypes and unimportant workloads without SLAs, and our analysis of Kratos says not to use it as the login system for a business-critical product on the open source build alone, because guaranteed CVE fixes, current enterprise builds and features such as SAML, SCIM, organization login and CAPTCHAs are tied to a valid Ory Enterprise License. The last push was 2026-07-29.
- Moving from Auth0
- The README has a section on migrating from Auth0, Okta and similar providers, describing Ory Hydra as the OAuth2 and OpenID Connect provider alongside Kratos for identity and user-facing flows, with client configuration and endpoints repointed and identities migrated into Kratos.
- First install step
- Full setup guide
# Install the Ory CLI if you do not have it yet: bash <(curl https://raw.githubusercontent.com/ory/meta/master/install.sh) -b . ory sudo mv ./ory /usr/local/bin/ # Sign in or sign up ory auth # Create a new project ory create project --create-workspace "Ory Open Source" --name "GitHub Quickstart" --use-project ory open ax login
supertokens/supertokens-coreOpen source alternative to Auth0 / Firebase Auth / AWS Cognito
- Best for
- You want login and session logic to live in your own infrastructure next to a database you already run, without adopting OAuth protocol complexity in your application. The README describes three building blocks, a frontend SDK that manages session tokens and renders login widgets, a backend SDK with the sign-up and sign-in APIs, and this Java HTTP service, plus passwordless, social, email and phone login, session management, multi-factor authentication and user roles.
- What you give up
- It is a Java HTTP service that has to be deployed and patched, and our analysis of SuperTokens Core says not to adopt it if you want a hosted identity provider with no operational surface. Multi-tenancy and organization support appear in the README's feature list under an Enterprise SSO heading, so if that is the capability you need, check the pricing page rather than assuming it ships in the open source core. The licence is in LICENSE.md.
A protocol server, a tenant model, a login page, and a headless API
Auth0 is a hosted identity service: login pages, social and enterprise single sign-on, multi-factor authentication and user management behind OAuth 2.0 and OpenID Connect. People look elsewhere for three reasons. Pricing by monthly active users. User records and sessions live with the vendor. And an identity provider that must run inside your own network is not an option at all.
Those reasons produce seven different answers, and the difference is mostly about what the project thinks an application is.
keycloak/keycloak is the protocol server. The README describes it as open source identity and access management for modern applications and services, providing user federation, strong authentication, user management and fine-grained authorization so applications do not deal with storing or authenticating users themselves. It runs as a standalone service and reaches applications through standard protocols, with client libraries, quickstarts and a Node.js adapter in companion repositories. It is also the most established of the seven: the README carries a CNCF Code of Conduct, and the project is one the wider foundation community tracks.
zitadel/zitadel is the tenant model. Its README builds the case around multi-tenancy first, describing a strict hierarchy of Identity System, Organizations and Projects with isolated data and policy scoping at several levels, SSO, MFA, passkeys, OIDC, SAML and SCIM, an API-first surface over connectRPC, gRPC and HTTP JSON, and a differentiator it describes as a relational core with an event-driven core, where every mutation is written as an immutable event so the audit trail is complete and streamable to external systems. It also states that its cloud and self-hosted versions run the same codebase.
goauthentik/authentik is the login page. The README describes an identity provider for modern SSO that supports SAML, OAuth2 and OIDC, LDAP and RADIUS, designed for self-hosting from small labs to large production clusters, and it positions its enterprise offering as a way to replace existing providers such as Okta, Auth0, Entra ID and Ping Identity.
authelia/authelia is the reverse proxy companion rather than an identity provider. The README is explicit that it acts as a companion for reverse proxies, allowing, denying or redirecting requests, and it lists nginx, Traefik, Caddy, Skipper, Envoy and HAProxy as the proxies it works with, plus Kubernetes ingress-nginx, the Traefik CRD and Ingress, Istio and Envoy Gateway.
logto-io/logto and ory/kratos are the developer-first pair. Logto describes itself as auth infrastructure for SaaS and AI apps with a pre-built sign-in experience and SDKs for more than 30 frameworks. Kratos goes the other way: an API-first system that centralises login, registration, recovery, verification and profile management so services consume them instead of reimplementing them, with identity schemas and traits at the centre.
supertokens/supertokens-core is in between, and the README makes the reasoning explicit: authentication affects user experience, developer experience and security at once, and the project argues that existing solutions force a choice between them, which is why applications hand-roll their own auth. Its three-part architecture is a frontend SDK, a backend SDK and this Java HTTP service.
Left out, and worth saying why: the session and cookie libraries that are not identity systems, and the identity providers bundled inside cloud platforms, which ship with the surrounding product and are not general purpose. Both exist; neither is what a team leaving a hosted identity service for network reasons is looking for.
Why Okta, Clerk and Firebase Auth are not on this list
Okta, Clerk and Firebase Auth are the three names that appear next to Auth0 in most of these searches, and none of them is here, because all three are hosted. Your user records and sessions live on their servers, which is the third reason on the list and the one that disqualifies them.
There is no argument against them on merit. Okta has been an enterprise identity provider for two decades and its directory integrations are a reason many organisations chose it. Clerk is unusually pleasant to integrate from a front-end framework and ships prebuilt components. Firebase Auth is already in the project for a large number of mobile teams, which is a real switching cost that has nothing to do with quality.
The reason they do not qualify is the combination of the other two reasons. Pricing by monthly active user is difficult to forecast when a product has seasonal traffic, and for a company with a requirement that the identity provider run inside its own network, the hosted option is not a trade-off to weigh, it is simply unavailable.
Also absent, and worth naming: the commercial vendors of open source identity providers. A hosted Keycloak or a hosted ZITADEL is a real product category, and it is a sensible middle path for a team that wants the protocol coverage of the open source project without operating a Java service. It also gives up the part that prompted the search.
One absence that gets missed: none of the seven here is a customer identity or access management suite with case management, delegated administration and an agent desktop. That is a different product with a different buyer, and it is not what an Auth0 search is about.
Choosing by scenario: a solo developer, a small team, a company with compliance needs, a developer embedding auth
The first question is who the users are, because these seven split cleanly between people you employ, customers in a shared product, and users of your own internal tools.
A solo developer building a side project should look at logto-io/logto. It gives you pre-built sign-in flows, customisable UI and SDKs for common frameworks, so the fastest path from nothing to working authentication is short. The cost is PostgreSQL and the knowledge that a weekly-to-monthly release cadence is now your problem, which our analysis of Logto tells you to think about before you commit rather than after.
A small team with an internal tool suite should look at authelia/authelia. It exists precisely for the case where a reverse proxy already fronts your applications and you want a single login in front of them without touching the applications. What you give up is a user system: it authenticates users, it does not manage them, so somebody else has to own registration and password recovery.
A company with compliance requirements is usually choosing between keycloak/keycloak, zitadel/zitadel and goauthentik/authentik, and the choice is about protocol coverage versus tenant modelling versus deployment fit. Keycloak is the widest and the most mature, and the one most existing libraries already know how to talk to. ZITADEL is the one built around organisations, with an event stream behind every change. authentik is the one with the widest protocol set, including LDAP and RADIUS, which matters when the systems you are connecting to are older than your user base.
A developer embedding auth in a product is the case with the sharpest trade. ory/kratos puts identity flows behind HTTP APIs and leaves the UI to you, which is maximum control and maximum work. supertokens/supertokens-core does the opposite: it ships login widgets and a backend SDK so you avoid protocol complexity, at the cost of running a Java service next to your database. logto-io/logto sits between them with a pre-built experience you can customise.
What each one asks you to run
The install commands on this page range from a proxy companion with no server of its own to a compose file that starts a database, and that spread is the operational story.
keycloak/keycloak shows docker run quay.io/keycloak/keycloak start-dev, and the README also describes downloading the distribution and running bin/kc.sh or bin/kc.bat with start-dev. That start-dev mode is a development convenience; the operational work is a persistent Java and Quarkus service, and our analysis of Keycloak asks you to confirm your team can operate one, to read the upgrade notes for the target version in RELEASES.md, and to decide whether the built-in database or an external one fits your deployment.
zitadel/zitadel has the most complete command on the page, and it is a real deployment rather than a smoke test: it fetches the compose file and the .env.example, copies the example environment file into place, and starts the stack with docker compose up and a wait for readiness. Underneath is PostgreSQL and a Go service, with deployment guides for Compose and Kubernetes. logto-io/logto offers two comparable routes, a compose file piped from a URL and npm init @logto with PostgreSQL required.
authelia/authelia has no install command in our analysis, and the README explains why by listing the shapes instead: a static binary, a .deb package, the AUR, APT, FreeBSD Ports, Docker, Kubernetes, and a Helm chart that it marks as beta. What it runs alongside is a remote database and Redis when you want high availability.
goauthentik/authentik also has no install command in our analysis; the README points at Docker Compose for small and test setups, a Helm chart for larger ones, AWS CloudFormation templates, and a DigitalOcean Marketplace app. ory/kratos and supertokens/supertokens-core differ again: the Kratos command on this page installs the Ory CLI and signs in, which is the managed path, while the self-hosted path is documented separately in its install guide; the SuperTokens command is a single image pull, and what you assemble around it is your database.
The pattern is worth stating plainly. Five of the seven are a service plus a database. One is a service that fronts something you already run. And one is a set of HTTP APIs that still needs a front end built by you.
Licences: Apache-2.0 in two places, AGPL-3.0, MPL-2.0, and three repositories to read
This is the part of an Auth0 migration that is decided in a meeting rather than in a terminal, and the seven here split into three groups.
keycloak/keycloak and ory/kratos are Apache-2.0. Both can be read, modified and run as a hosted service, and the Keycloak README states the licence explicitly. Kratos adds a separate commercial layer rather than a separate licence: the Ory Enterprise License sits on top of the self-hosted server and brings SCIM, SAML, organization login, CAPTCHAs and regular security releases including CVE fixes. The important detail is in the README's own framing, which our analysis repeats: the open source distribution is positioned for individuals, researchers, prototypes and unimportant workloads without SLAs. Running it as the login system for a business-critical product is a decision to make deliberately, not by default.
zitadel/zitadel is AGPL-3.0, and the network clause is the part to think about. If you modify it and expose it to users over a network, the source obligation applies. Our analysis of ZITADEL also points at LICENSING.md as the file that tells you whether your distribution model is covered, which is worth reading before a product decision rather than after.
logto-io/logto is MPL-2.0, which is file-level copyleft. If you modify a file in the project you owe that file back; if you are only running it, there is nothing to negotiate.
goauthentik/authentik and supertokens/supertokens-core are the two that need a file opened. The authentik repository is a custom licence as far as GitHub is concerned and links three licence files, one of them at authentik/enterprise/LICENSE, and our analysis says to read that rather than assume one licence covers the repository. SuperTokens Core is likewise a custom licence, and the analysis points at LICENSE.md as the thing to check against how you intend to redistribute the service, and warns against assuming that a feature listed under an Enterprise SSO heading ships in the open source core.
One point applies to all seven. An identity provider holds credentials and session tokens, and the licence on the software says nothing about the data in it.
Bottom line
Pick authelia/authelia when a reverse proxy already fronts your internal tools and you only need a login in front of them, logto-io/logto for a product that wants pre-built sign-in flows and SDKs, ory/kratos when you want identity flows as HTTP APIs and are willing to build the front end, supertokens/supertokens-core when you want login widgets and a session service next to your own database, keycloak/keycloak for protocol coverage and maturity, zitadel/zitadel when multi-tenancy and an event stream are the problem you are solving, and goauthentik/authentik when LDAP or RADIUS has to sit behind the same login. Before committing, read the licence file that covers the features you plan to enable, decide built-in versus external databases, and check that your reverse proxy or network topology passes what each one needs.
Sources
- Auth0 official site
- keycloak/keycloak repository
- keycloak/keycloak README
- zitadel/zitadel repository
- zitadel/zitadel README
- goauthentik/authentik repository
- goauthentik/authentik README
- authelia/authelia repository
- authelia/authelia README
- logto-io/logto repository
- logto-io/logto README
- ory/kratos repository
- ory/kratos README
- supertokens/supertokens-core repository
- supertokens/supertokens-core README