If you are looking for a ZITADEL alternative, you already have a reason. The license did not survive legal review, or you hit a ceiling on the hosted plan, or running an event sourced identity system turned into more operational work than anyone signed up for. That reason matters more than any feature table, because most roundups on this query rank identity providers by checkbox and stop there.
What follows is organized by the shape of the problem rather than by vendor, because the options that replace ZITADEL are not interchangeable. It also covers the failure mode that can send a team back to the drawing board once the migration is done, which is discovering that the problem they wanted fixed was permissions, not the identity provider.
Why developers look for a ZITADEL alternative
Start with licensing, since it can take the decision outside engineering entirely. ZITADEL's main repository moved from Apache 2.0 to AGPL-3.0 with v3, released on 2 May 2025, so if you evaluated it before then, the terms you remember are not the terms you get now. What that actually means for you depends on how you deploy, modify, and distribute it. ZITADEL's licensing FAQ says unmodified distributions are generally permissible and describes a commercial license for cases where the AGPL terms do not fit. So this is a question for counsel about your specific setup rather than a blanket blocker on commercial use. Plenty of teams get through it fine. Others decide a permissive license is one less thing to argue about.
The hosted plan limits matter too. ZITADEL Cloud's free tier covers 100 daily active users and three identity providers, and the Pro plan starts at $100 a month with 25,000 daily active users and the same three identity providers included. Check those against your own growth forecast, because the point where you cross a tier is much easier to plan for than to discover.
Then there is the operational profile. ZITADEL is written in Go with a relational core and an event driven design, which gives you an append only record of state changes and a strong audit history. If you self-host, database capacity, backups, monitoring, and upgrade testing need an owner, and v3 dropped CockroachDB support in favor of PostgreSQL, which is its own migration if you were on the former. ZITADEL Cloud covers that operational work for you. Finally the tenancy model is opinionated. Organizations, projects, and role grants are first class, which saves real work when your product maps onto them and creates friction when it does not.
The four shapes a ZITADEL replacement comes in
The options here fall into four practical categories, and picking the category correctly matters more than picking the product inside it.
| Shape | Options | Fits when |
|---|---|---|
| Full self-hosted identity platform | Keycloak, Authentik | You need SAML, LDAP federation, and an admin console you can hand to IT |
| Reverse proxy SSO | Authelia | You are protecting self-hosted services behind a proxy you already run |
| Composable identity services | Ory | You want to assemble only the pieces you need and own the integration |
| Managed or SDK first login | Auth0, Clerk, SuperTokens, Better Auth, Hanko | Login is a feature of your app, not infrastructure you want to operate |
Keycloak and Authentik cover the full self-hosted platform
Keycloak is the heavyweight. It is a Cloud Native Computing Foundation incubation project under the Linux Foundation, and it speaks OpenID Connect, OAuth 2.0, and SAML with directory federation and identity brokering on top. If you need LDAP federation against Active Directory, or SAML federation with a customer's own identity provider, that ground is well covered. The cost is weight. It expects a database, meaningful memory headroom, and someone who understands how realms isolate users, clients, and configuration before you depend on it in production. We went through the wider landscape in our Keycloak alternatives piece, and the head to head against ZITADEL specifically is here.
Authentik has an MIT licensed core with separately licensed enterprise features. It is Python based and built around flows, a configurable pipeline of stages a login passes through, so enrollment, recovery, and step up authentication become explicit pipelines rather than fixed templates. Its proxy outpost puts authentication in front of applications that speak no modern protocol at all. For an estate that includes applications with no OpenID Connect support, covering both modern and legacy applications with one tool can be the deciding factor. We compared it directly to ZITADEL in a separate piece.
Authelia fits a self-hosted estate behind a reverse proxy
Authelia is built for a narrow job and does it well. It is written in Go, Apache 2.0 licensed, and designed as an OpenID Connect 1.0 provider and reverse proxy companion rather than a standalone platform, working with nginx, Traefik, Caddy, Envoy, and HAProxy through forward authentication. It handles WebAuthn security keys, time based one time passwords, and push notifications.
What it does not do is SAML, and it is not trying to be a customer identity platform for your product. If you are protecting internal services behind infrastructure you already operate, Authelia will do it without running a full identity platform. If you are issuing identity to your customers, it is the wrong shape.
Ory lets you assemble only the identity pieces you need
Ory takes the opposite approach to a single platform. It ships separate Apache 2.0 licensed services. Kratos handles identity and self-service flows, Hydra acts as the OAuth 2.0 and OpenID Connect provider, Polis covers enterprise SAML and directory sync, and Oathkeeper does proxy level access control, among others. You run only what you need.
That is genuinely appealing if you want token issuance without a user management platform bolted to it, and it is a real cost if you wanted one thing to install. Ory fits when you need separately deployable identity components and can own the integration between them, along with the operational surface and the upgrade coordination that come with it. Our Keycloak and Ory comparison goes deeper into that trade.
Managed and SDK first options treat login as a product feature
The last group starts from a different premise, which is that login belongs close to your application rather than in a platform you administer. How much you operate still varies inside it. Auth0 and Clerk are managed services, SuperTokens and Hanko offer both a managed option and a self-hosted one, and Better Auth is a library that runs inside your own application.
Auth0 is the established managed option, with the protocol coverage and enterprise connections a long-running platform accumulates. Check its current pricing against your user numbers, since that is usually what decides it. Clerk targets application teams directly with prebuilt components and organization support, which shortens the distance between starting and shipping.
SuperTokens sits in between, with a core you can self-host or use as a managed service and backend and frontend SDKs that keep the login surface inside your application. It covers passwordless, social login, passkeys, multi-factor authentication, and multitenancy with enterprise single sign-on. We put it head to head with Ory previously.
Two newer entrants round out this group. Better Auth is a framework agnostic TypeScript authentication library with a plugin ecosystem covering multitenancy and single sign-on, which suits a team that wants login inside the application rather than behind an API. Hanko is a full authentication and user management product covering passwords, passkeys, two-factor authentication, and single sign-on, with a strong passkey focus and both self-hosted and cloud deployment. Both are newer than the rest of this list, so check release history and security advisories against how long you expect to live with the decision.
Switching identity providers rarely fixes a permissions problem
Before treating a migration as the answer, test whether the unmet requirement is identity, authorization, or both. Often login works fine and permissions are the part that does not. Someone asked for a rule like editors can modify documents in their own tenant, but only during business hours, only if the document is not locked, and only if they are the assigned owner. That requirement went to the identity provider, the identity provider offered roles, and roles were not enough.
The options above differ more than a roundup usually admits. Keycloak's authorization services cover resources, scopes, policies, and permissions, including context based rules. ZITADEL has project roles and organization grants. Others hand your application a session or a token carrying roles and groups and leave the rest to you. So the question is not whether an identity provider can express authorization at all. It is whether the model it gives you can carry the rules your application actually needs, and whether you want those rules living inside the identity provider or in one place that every service shares.
The difference between authentication and authorization is that authentication proves who someone is, while authorization decides what that person can do with a specific resource under specific conditions. A role claim on its own tells you someone is an editor. It does not tell you whether this editor can touch this record right now.
Broken access control holds the number one spot in the OWASP Top 10 for 2025, where 100% of applications tested were found to have some form of it, and it carries the highest number of occurrences in the contributed data. Those are enforcement failures rather than login failures, which puts them in a different layer of the stack from the one you are shopping in.
So if permissions are the actual driver, test the candidate against your real rules before you move. Write two or three representative decisions, the awkward ones with ownership and state in them, and check whether the model on offer can express them and whether you can govern them across services once it does. A migration that skips that step tends to relocate the problem rather than solve it. The question to answer first is which layer is failing, and we wrote up a framework for working that out. If you are on Keycloak already, the same analysis applies to what it leaves you.
How a dedicated authorization layer works alongside any of these
In practice this means your services stop carrying permission conditions in their own code and ask one question instead. The division that holds up over time is to let the identity provider authenticate users, and to let a separate authorization layer evaluate each request against your rules.
That is what the Cerbos authorization management platform is for. Your identity provider authenticates the user and issues a token. Cerbos takes that identity along with the attributes of the resource and the request and answers one question, which is whether this user or service can perform this action on this resource right now. The decision point is stateless, holding no user database and no session state, so it can run next to each service as a sidecar or behind a Unix socket and keep the call local instead of crossing the network. Your application still waits for the decision before it enforces anything. Across deployments the platform serves more than 2 billion authorization checks a month.
Policies are YAML with conditions written in Common Expression Language, versioned and reviewed in pull requests like the rest of your code, which means changing a permission no longer means changing application code. Cerbos Hub is the control plane for that side of the platform, authoring, testing, and distributing policies to your decision points without restarts, while the decision points do the request-time evaluation. Turn on audit logging with a backend configured and those decision points record what was allowed and why, which is the kind of evidence your own compliance audit asks for. The rules that depend on tenant, ownership, plan, or object state move out of application code and into one place, which is the model behind multi-tenant authorization that does not fork per customer.
It is designed to sit behind whatever you pick. The ZITADEL integration shows the shape if you end up staying, where your application passes the OIDC claims it already receives, including project roles and organization grants, as principal attributes, Cerbos evaluates them against the resource and action, and your application enforces the result. The same pattern applies to Keycloak, Authentik, Ory, and the managed options, since the calling application supplies the context in each case. The same decision path covers non-human identities too, which matters as service accounts and AI agents start making requests that need the same contextual checks as people.
What to inventory before you commit to a migration
A second migration usually traces back to a first one that was scoped to the login screen. Write down five things before you pick.
Start with the protocols you actually depend on today, including SAML and directory federation, since that is where the sharpest differences between these options sit. Then work out how users and credentials move, because password hashes, multi-factor enrollments, and linked external identities do not all transfer cleanly. Describe what your tenancy model needs in concrete terms, as delegated administration, organization hierarchy, tenant scoped roles, or customer federation, rather than as the word multi-tenant. Name who owns the service after go-live, since a self-hosted platform needs someone accountable for upgrades and backups. Finally, list the access rules that live in application code today, because those decide whether identity is the layer you are actually replacing.
Skipping that last one is what causes the second migration.
Choosing a ZITADEL alternative without migrating twice
Start by naming the reason you are leaving, because it selects the category for you. A licensing problem points at Keycloak, Authelia, or Ory, all Apache 2.0, or at Authentik, which is MIT apart from its separately licensed enterprise features. A plan ceiling points at self-hosting, provided you can absorb the operational cost that comes with it. An operational burden points the other way entirely, toward a managed service where somebody else carries the upgrades. A tenancy mismatch needs a more specific answer, depending on whether what does not fit is delegated tenant administration, organization hierarchy, tenant scoped roles, or customer federation.
Then separate the two questions before you migrate anything. Decide who proves identity, and decide separately where access decisions live. Teams that answer both at once tend to answer the second one by accident, inside whichever identity provider they just chose, and carry the same limitation onto a new platform. Answering them separately means the identity decision gets easier, because you are choosing an authentication system on its authentication merits rather than hoping it grows into something it was never built to be.
Getting started
If you want to see what the authorization half looks like in practice, try Cerbos and write a policy against your own resources, or book a call to talk through mapping your identity provider's tokens and your resource model onto policies.
Go deeper: How to adopt externalized authorization (eBook) for moving permission logic out of application code without a rewrite
FAQ
Tagged in
