At a glance — how these 6 alternatives compare
Our read on each project's adoption, maintenance activity and commercial-use risk, derived from GitHub signals and SPDX license terms rather than star count alone. Sorted by stars. How we score.
| Project | Adoption | Maintenance | Commercial use |
|---|---|---|---|
| ★ 37,004 · Java Apache-2.0 | Flagship | Active | Low risk Embed in a proprietary product with no copyleft obligation |
| ★ 29,099 · Go Apache-2.0 | Mainstream | Active | Low risk Embed in a proprietary product with no copyleft obligation |
| ★ 25,741 · Python | Mainstream | Active | Low risk Embed in a proprietary product with no copyleft obligation. Split licence — this rates the core component; read the † text for the separately licensed parts |
| ★ 15,322 · Java | Mainstream | Active | Low risk Embed in a proprietary product with no copyleft obligation. Split licence — this rates the core component; read the † text for the separately licensed parts |
| ★ 15,113 · Go AGPL-3.0 | Mainstream | Active | High risk Even a hosted/modified deployment can trigger source release |
| ★ 13,894 · Go Apache-2.0 | Mainstream | Active | Low risk Embed in a proprietary product with no copyleft obligation |
† Licenses marked † were read from the repository's LICENSE file on 2026-09-05 (linked, pinned to the commit we read) because the GitHub API returned no SPDX id for them. Unmarked licenses are the GitHub API's SPDX classification.
The alternatives
keycloak
Open Source Identity and Access Management For Modern Applications and Services
keycloak/keycloak Updated 2026-09-27 authelia
The Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.
authelia/authelia Updated 2026-09-27 The authentication glue you need.
goauthentik/authentik Updated 2026-09-27 Open source alternative to Auth0 / Firebase Auth / AWS Cognito
supertokens/supertokens-core Updated 2026-09-25 zitadel
ZITADEL - Identity infrastructure, simplified for you.
zitadel/zitadel Updated 2026-09-25 kratos
Headless 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.
ory/kratos Updated 2026-07-29 Editor's take
Yusuke Morinaga · last revisited · star counts quoted in the text (≈) are as of that date; the cards above are refreshed daily
Why the Auth0 alternatives list looks like one decision but is actually three.
The six projects above all show up under “open-source Auth0 alternative”, but they are not interchangeable. Method note: I have not load-tested these in production myself — the comparison below comes from their architecture docs, deployment guides, and the postmortems and migration threads their operators publish. The split that emerges from that reading is not “which has the most stars” — it is what shape of identity problem you actually have.
The license trap nobody warns you about
Of the six, ZITADEL ships under AGPL-3.0. That license is a non-event
for an internal deployment you do not modify, but if you are planning to embed the
identity layer into a closed-source SaaS that customers self-host, AGPL
section 13 does trigger — your SaaS users are “interacting with the
software over a network”, which forces source disclosure of your modifications
to ZITADEL. Keycloak, Authelia, and Kratos under Apache-2.0 do not have that
constraint. For Authentik and SuperTokens the GitHub API returns no SPDX id,
so the cards show what we read in each repository’s LICENSE — in both cases
the core licence is permissive
(Apache-2.0 for the non-ee/ parts of supertokens-core, MIT for the
Authentik core), but the SuperTokens repo also contains an ee/ directory
under a separate enterprise licence, and Authentik’s enterprise modules are
similarly carved out. Audit the exact directories you are pulling in and
re-check on every minor bump. This is the kind of thing that does not show
up in star counts.
When Keycloak is wrong despite being the obvious pick
Keycloak’s ≈36.6k★ are real and the project is healthy. Since v17 the default distribution is Quarkus-based (the WildFly distribution was deprecated and then removed), which lowered startup time and memory footprint meaningfully, but the operational reality is still that you are running a JVM service backed by an external Postgres, and a highly available deployment means several Keycloak nodes behind a load balancer plus that database. Keycloak’s own server guide documents the sizing and clustering setup — read it before assuming the footprint is small. If you are migrating from Auth0 because of the per-user bill, Keycloak trades that bill for infrastructure plus the engineer-time to keep the JVM and the realm configuration honest. For B2B SaaS with hundreds of tenant realms and a team that is comfortable running JVM services in production, that is a no-brainer. For a five-person startup doing social login on a Next.js app, it is still overkill — SuperTokens or Kratos will be faster to integrate and cheaper to run.
The Ory split (Kratos vs the rest)
Ory Kratos is the only project in this list that is deliberately headless — there is no login UI. You build the login form in your app and call the Kratos API. This is the right answer if your design team already owns the login flow and you do not want to fight a Keycloak theme. It is the wrong answer if you want the identity provider to also be your login UI out of the box, which is what most people coming from Auth0 expect. Read the first 30 lines of the Kratos quickstart before you commit — the headless model is the project’s deliberate stance, not a missing feature.
What actually shifted in the last 12 months
Authentik landed enterprise SSO connectors that made it competitive with Keycloak on the SAML-heavy enterprise side, which was not true a year ago. SuperTokens shipped self-hosted with a SQLite option, which is a viable single-binary setup for very small deployments. ZITADEL keeps expanding the managed cloud offering, which is fine, but means you should re-confirm that the AGPL self-hosted version is not lagging the managed one on the auth methods you need — the gap is worth checking on every quarterly review.
My actual recommendation
If you have a security engineer and need SAML, OIDC, and federation in one box: Keycloak. If you want headless and own your UI: Kratos. If you want the smallest possible footprint and a familiar dashboard: Authentik. The other three are perfectly good projects but ranked behind these three on the trade-offs that dominate operators’ write-ups — upgrade pain, session model rigidity, and how much of the spec you actually need.
Comparison notes
Keycloak is the most feature-complete OSS identity provider, covering OIDC, SAML, social login, MFA, and fine-grained authorization. It matches or exceeds Auth0 on protocol support. The gaps: Keycloak is a Java application with significant operational overhead — JVM tuning, clustering for HA, and a steep learning curve on its admin console. Auth0's Actions (JavaScript hooks for login flows), its anomaly detection, and its breached password detection have no direct Keycloak equivalent. Self-hosting auth is higher risk than most infrastructure choices — factor in incident response capability.
Migration tips
- Export Auth0 user data via the Management API (/api/v2/users) in JSON or CSV; passwords are hashed and cannot be exported — plan for password reset on first login
- Map your Auth0 tenant's social connections to Keycloak's identity provider configuration one by one
- Audit Auth0 Rules and Actions (pre-migration hooks, post-login logic) and rewrite them as Keycloak event listeners or script authenticators
- Test MFA enrollment flows with a pilot group before migration — TOTP secrets are not transferable between platforms
- Update all application OIDC configurations (client_id, redirect_uri, discovery endpoint) and test token validation in each service
Which alternative should you pick?
Replacing Auth0 isn't a single call — it's a trade between license terms, team size, and how much early-stage roughness you can absorb. The 6 projects above split along those lines:
- You want the project with the most GitHub stars in this list → keycloak. 37,004★ — the most of the 6 projects here. Stars measure attention, not quality or maintenance; check the last-push date and the Editor's take before reading more into it.
- You want a copyleft project whose modifications must be shared back → zitadel. AGPL-3.0 licensed — distributing a modified version (and, under AGPL, offering it over a network) obliges releasing the source, which is what some teams explicitly want.
- You want the project with the most recent push activity → authelia. Last push 2026-09-27 — the freshest activity in this list.
License & commercial-use notes
When replacing Auth0, the license usually decides more than the feature list — whether you can modify it, ship it inside a product, or host it as a service. The 6 projects here fall into:
- Permissive (keycloak, authelia, authentik, supertokens-core, kratos) — MIT / Apache / BSD / ISC — modify and embed inside a commercial product with no copyleft obligation. The safest bucket for shipping in a proprietary codebase.
- Network copyleft (zitadel) — AGPL / SSPL — the copyleft trigger extends to offering the software over a network, so a hosted deployment of a modified version can oblige you to publish your changes. Read the exact terms before building a paid hosted product on these.
Split licences: authentik (MIT (core) + separate license for authentik/enterprise/); supertokens-core (Apache-2.0 (core) + separate license for ee/). These projects are grouped above by the core licence; the separately licensed directories (enterprise or EE parts) are not covered by that bucket — check which files you actually ship.
License fields come from the GitHub API's SPDX classification and can lag a relicense. Where the API returned no SPDX id, the license marked † was read from the repository's LICENSE file on 2026-09-05; the † links to the exact file and commit we read. The repository linked on each card is authoritative — confirm its LICENSE file before any license-sensitive deployment.
Maintenance health of these 6 projects
Of the 6 projects listed, 6 shipped at least one commit in the last 12 months. See how we rank for the full criteria and our self-hosting cost reality check, which apply across every comparison on this site.
Frequently asked questions
How do these 6 alternatives compare on maintenance health?
6 of 6 have shipped a commit in the last 12 months. At least one project here has 5,000+ GitHub stars. Always check the last-pushed date in the cards above and read the latest closed issues — those two signals are the fastest public check we know of.
How this page was compiled
- Repository facts (stars, license, language, last push) come straight from the GitHub public API and are linked on each card as the primary source. Where the API returned no SPDX id, the licence marked † was read from the repository's
LICENSEfile (linked, pinned to the commit we read, with the date checked). - Editorial analysis (the intro, comparison notes and migration tips) is Claude-drafted from Auth0's use case and the alternatives' repository metadata — in Claude Code sessions or scheduled routines run under the operator's account. Samples are spot-checked against the upstream repositories; entries are not individually reviewed unless they carry a signature. See what Claude drafts and what the operator writes.
- Editor's take is signed by Yusuke Morinaga. It was drafted in a Claude Code session the operator ran, then read and confirmed by Yusuke Morinaga before publication, and carries the date it was last revised. It is written from each project's README, LICENSE, release history and issue tracker — not from running the project in production; where that distinction matters, the take says so.
- Maintenance signal: 6 of 6 projects shipped a commit in the last 12 months as of the latest rebuild (most recent activity: ).
- Last editorial review: by Yusuke Morinaga.
- Spotted an error? Email [email protected] with the page URL (subject prefix
[correction]) — we ship corrections within 14 days.