---
title: "Best Keycloak alternatives"
description: "Compare Keycloak alternatives by protocol, deployment model, limitations, and migration path. Covers ZITADEL, Authentik, Authelia, SuperTokens, and Ory Hydra, plus when to keep Keycloak and add Cerbos for fine-grained authorization instead."
author: "S. B. Writer"
date: "2026-09-02T16:02:16.087Z"
canonical: "https://www.cerbos.dev/blog/best-keycloak-alternatives"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Keycloak_alternatives_ce158fcf1a.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/best-keycloak-alternatives"
---

# Best Keycloak alternatives

[Keycloak](https://www.cerbos.dev/ecosystem/cerbos-keycloak) is an open-source identity and access management platform that supports [OpenID Connect, OAuth 2.0, SAML 2.0](https://www.keycloak.org/securing-apps/specifications), identity brokering, and LDAP or Active Directory federation. The reason to replace it should therefore be tied to a specific operational or architectural requirement, not a generic claim that it is "too complex."

This guide evaluates alternatives by verifiable criteria rather than broad labels such as "lighter," "more enterprise-ready," or "easier to upgrade." It also explains when replacing Keycloak is the wrong move and a dedicated authorization layer is the cleaner architecture.

## **Which Keycloak alternative fits your requirement**

Choose the product category first. A reverse-proxy authentication gateway, an OAuth server, a full identity provider, and an authorization policy engine solve different problems even when all of them appear in "Keycloak alternative" lists.

| Your actual requirement | Start with | Why |
| :---- | :---- | :---- |
| A full self-hosted IdP with OIDC, SAML, directory integration, admin workflows, and mature IAM features | Keep Keycloak or evaluate Authentik | Both cover multiple identity protocols and identity administration. Authentik is especially relevant when proxy-based protection and custom flows matter. |
| Cloud-native B2B identity, organization-level multi-tenancy, APIs, Terraform, and a managed option | ZITADEL | ZITADEL documents SAML, external LDAP identity providers, stateless scaling, an explicit per-version setup phase, and Terraform management. |
| SSO and MFA in front of reverse-proxied applications, with limited application-level identity requirements | Authelia | Authelia is designed around reverse-proxy enforcement and includes an OpenID Connect provider, still documented as beta, whose access rules operate at the request and endpoint layer. |
| SDK-first login, sessions, passwordless, social login, and fast integration inside a product | SuperTokens | SuperTokens focuses on application authentication and session management. Enterprise SAML and some advanced features are paid capabilities. |
| A dedicated OAuth 2.0 and OpenID Connect token service while user login and consent remain elsewhere | Ory Hydra | Hydra issues tokens and delegates login and consent to another application. It is not a user directory or a complete IdP. |
| Your IdP works, but permissions depend on tenant, resource, plan, ownership, or other runtime attributes | Keep Keycloak and add Cerbos | Cerbos evaluates principal, resource, action, and context outside application code, and can pull live roles and groups from Keycloak at decision time. |

## 

## **Identify which layer is failing before comparing Keycloak alternatives**

* Identity provider. User accounts, federation, login flows, MFA, token issuance, and administrative lifecycle. Keycloak, ZITADEL, and Authentik mainly compete here.  
* Authentication gateway. Centralized sign-in and MFA in front of applications, commonly through a reverse proxy. Authelia is strongest in this category.  
* Application authentication. SDKs, session handling, login UI, passwordless, and social login embedded in a product. SuperTokens is designed around this workflow.  
* OAuth and OIDC authorization server. Standards-compliant token issuance that connects to an external login and consent system. Ory Hydra fits this narrower role.  
* Authorization policy decision point. Allow and deny decisions after authentication, based on the principal, resource, action, and runtime context. Cerbos fits here and complements an IdP rather than replacing one.

## **Why teams replace Keycloak, operational topology and authorization limits**

Keycloak's operational cost is not adequately described by saying it is "hard to configure." The relevant question is what production topology you need. Its [high-availability guidance](https://www.keycloak.org/high-availability/introduction) covers single- and multi-cluster architectures, while the [Kubernetes deployment guide](https://www.keycloak.org/high-availability/multi-cluster/deploy-keycloak-kubernetes) describes a load-tested setup. These requirements are appropriate for some organizations and unnecessary overhead for others.

Evaluate upgrades against your extensions, themes, identity-provider integrations, token mappings, and database procedures. Instead of assuming that upgrades are unpredictable, test the relevant [upgrade guidance](https://www.keycloak.org/documentation) in your own topology and confirm rollback before production rollout.

The second reason is authorization, and here the picture changed recently. Keycloak has long shipped roles and Authorization Services, including UMA-related capabilities, and [Keycloak 26.7](https://www.keycloak.org/docs/latest/release_notes/index.html) added an AuthZEN evaluation endpoint that lets applications send a subject, resource, and action and receive a permit or deny decision. That endpoint is experimental and sits behind the authzen feature flag, so it needs its own evaluation before anyone plans around it.

Those features decide permissions from data Keycloak already holds, which covers role and group checks well. Application permissions often depend on data that changes at request time, including resource ownership, tenant, subscription plan, geographic boundary, risk score, or object state. That data lives in your services and your database, not in the directory, and moving the logic to a different IdP rarely solves the underlying design problem.

## **ZITADEL, a Keycloak alternative for cloud-native B2B identity**

[ZITADEL](https://www.cerbos.dev/ecosystem/cerbos-zitadel) is a cloud-native IdP with OIDC/OAuth2, SAML, passwordless authentication, organization-level multi-tenancy, APIs, Terraform, and self-hosted or managed deployment. It is strongest for B2B SaaS teams that want tenant-aware identity and infrastructure-as-code operations.

Not a fit without a proof of concept if applications must consume an LDAP endpoint from the IdP or depend on Keycloak Authorization Services. ZITADEL can use [LDAP as an external identity provider](https://zitadel.com/docs/guides/integrate/identity-providers/ldap), which is a different capability. Verify SAML mappings, identity and MFA migration, database recovery, and the documented [upgrade and scaling process](https://zitadel.com/docs/self-hosting/manage/updating_scaling) before switching. We have a longer [Keycloak and ZITADEL comparison](https://www.cerbos.dev/blog/keycloak-vs-zitadel) if you are weighing those two specifically.

## **Authentik, a Keycloak alternative for mixed legacy and modern estates**

[Authentik](https://www.cerbos.dev/ecosystem/cerbos-authentik) supports OIDC/OAuth2, SAML, LDAP, SCIM, customizable flows, and proxy-based protection. It is a strong candidate for mixed modern and legacy application estates where some applications cannot integrate directly with a standard identity protocol.

It is less attractive when the goal is the fewest possible components. [Proxy and directory scenarios](https://docs.goauthentik.io/add-secure-apps/providers/proxy/) can require separately deployed [outposts](https://docs.goauthentik.io/add-secure-apps/outposts). Verify which applications need an outpost, how those components are upgraded and monitored, and whether custom mappings or flows create long-term maintenance work. Our [Authentik and Keycloak comparison](https://www.cerbos.dev/blog/authentik-vs-keycloak-selfhosted-idp-comparison) goes through the protocol and deployment differences in more detail.

## **Authelia, a Keycloak alternative for reverse-proxy SSO and MFA**

[Authelia](https://www.cerbos.dev/blog/authelia-vs-authentik-2026-idp) is an authentication and access-control service designed primarily for applications behind reverse proxies. It provides SSO, MFA, WebAuthn, centralized sessions, an OIDC provider, and rules based on domains, paths, networks, and authentication level.

One detail matters if you are replacing a full IdP. Authelia's OpenID Connect provider is [OpenID Certified](https://www.authelia.com/blog/we-are-now-openid-certified/) but its own documentation still describes it as a beta feature, and the [roadmap](https://www.authelia.com/roadmap/active/openid-connect/) lists work that has not shipped yet. Plenty of teams run it in production, and you should still make that call deliberately rather than by assuming parity with Keycloak.

Choose Authelia for internal tools and reverse-proxied applications. Do not treat it as a universal Keycloak replacement when you need SAML, broad identity lifecycle management, or authorization over application resources such as projects and invoices. Verify [rule ordering and default-deny behavior](https://www.authelia.com/configuration/security/access-control/), directory integration, and the outage path.

## **SuperTokens, a Keycloak alternative for SDK-first application login**

[SuperTokens](https://www.cerbos.dev/ecosystem/cerbos-supertokens) is an SDK-oriented authentication system focused on login methods, sessions, account linking, multi-tenancy, and product integration. It suits teams that want authentication embedded in their application rather than a broad enterprise identity administration platform.

It does support [enterprise SAML](https://supertokens.com/docs/authentication/enterprise/saml) and [MFA](https://supertokens.com/docs/additional-verification/mfa/initial-setup), so the real trade-off is the paid feature set and SDK-centric architecture, not an absolute lack of enterprise login. Verify licensing, supported stacks, password and session migration, tenant onboarding, and compliance requirements.

## **Ory Hydra, a Keycloak alternative for standalone OAuth 2.0 token issuance**

[Ory Hydra](https://www.cerbos.dev/ecosystem/cerbos-ory) is an OpenID Certified OAuth 2.0 and OpenID Connect server. It issues and validates tokens but deliberately delegates user identity, login, and consent to another application.

Choose Hydra only when that separation is intentional and you already own the surrounding identity experience. It is not a ready-made user directory, login UI, password recovery system, or full IdP. The [self-hosted quickstart](https://www.ory.com/docs/oel/hydra/quickstart) demonstrates the additional login and consent component, and it now sits under Ory's Enterprise License documentation, which is worth registering if you are evaluating Hydra as an open-source Keycloak replacement. Verify its ownership, key management, persistence, admin API protection, and operational cost. Teams that want the identity half from the same project usually pair Hydra with Ory Kratos, which adds another component to operate, so count that in the comparison against a single Keycloak deployment.

## **Keep Keycloak and add Cerbos when fine-grained authorization is the real problem**

[Cerbos](https://www.cerbos.dev/) is not an identity provider and does not replace Keycloak login, MFA, federation, or token issuance. It is an authorization management platform that evaluates access decisions outside application code, against policies written in YAML with CEL conditions. It runs as a stateless service with no database of its own and no coordination between instances, so it does not add a second version of the Keycloak topology problem. This pattern is useful when permissions depend on tenant, resource, ownership, subscription plan, or other runtime context.

Common scenarios:
* Multi-tenant SaaS where access depends on tenant membership, resource tenant, subscription plan, contract terms, or customer-specific roles.
* Microservices where several services need the same authorization logic and policy changes should not require a release of every service.
* Data and AI systems where a user or agent may access only particular datasets, tools, records, or actions based on runtime context.
* Applications where resource ownership, lifecycle state, geographic boundary, or risk attributes must be evaluated alongside roles.

### **How Keycloak and Cerbos fit together in a single request**

1. The user authenticates with Keycloak. Keycloak issues an access token containing stable identity claims such as subject, issuer, audience, tenant or organization ID, and selected roles or groups.

2. The application validates the token, builds a Cerbos principal from trusted claims, and adds request-specific context. Cerbos can also [decode and verify JWT claims](https://docs.cerbos.dev/cerbos/latest/recipes/authentication/jwt/index.html) itself when auxData is configured, making those claims available inside policy conditions.

3. For a protected operation, the application sends principal, resource, action, and relevant attributes to Cerbos through an SDK, gRPC, or [REST API](https://docs.cerbos.dev/cerbos/latest/api/index.html). For example, principal tenant is acme, resource tenant is acme, and the action is approve.

4. Cerbos returns allow or deny and can return policy outputs. For list or search endpoints, the [PlanResources API](https://docs.cerbos.dev/cerbos/latest/api/index.html) produces a query plan that the application converts into a database filter, so you are not fetching rows only to discard them.

5. The application remains the policy enforcement point. It must deny the request when Cerbos denies it, and must never trust client-supplied tenant, plan, role, or ownership attributes without server-side validation.

### **Pull Keycloak roles and groups into policies without changing application code**

Step 2 above assumes each application assembles the principal itself. That works, and it means every service needs to know which claims matter and what to do when a role changes after the token was issued.

[Cerbos Synapse](https://www.cerbos.dev/ecosystem/cerbos-keycloak-enrichment) removes that work. Synapse queries the Keycloak Admin API with a service account at decision time and attaches the user's profile, composite realm roles, and group memberships to the principal before policies are evaluated. Cerbos [derived roles](https://docs.cerbos.dev/cerbos/latest/policies/derived_roles.html) then map that live directory data onto policy rules.

Two things follow from that. Policies read current Keycloak state rather than whatever was stamped into a token, so revoking a role takes effect without waiting for a token refresh. And the enrichment happens in one place instead of in every service that needs it.

## **Key takeaways: How to choose between Keycloak alternatives**

* Keep Keycloak when its identity functions work and the team can operate the required topology. Do not replace it only because application permissions have become complex.  
* Choose ZITADEL for cloud-native B2B identity and infrastructure-as-code workflows, but distinguish consuming LDAP as an external IdP from exposing LDAP to applications.  
* Choose Authentik for mixed modern and legacy application estates where proxy providers, outposts, custom flows, and multiple protocols are useful.  
* Choose Authelia for reverse-proxy SSO and MFA, checking the beta status of its OIDC provider against your risk tolerance, and not as a universal resource-authorization engine.  
* Choose SuperTokens for SDK-first application authentication, while pricing the enterprise features your roadmap needs.  
* Choose Ory Hydra only when you intentionally want a separate OAuth and OIDC token service and already have login, consent, and user management elsewhere.  
* Add Cerbos when authorization depends on runtime business context. Keep decisions close to workloads, enrich them with live directory data, test latency, and define fail-closed behavior before production rollout.

## FAQ

### What is the best Keycloak alternative for self-hosted IAM?

The best Keycloak alternative for self-hosted IAM depends on which layer is causing the problem, because these products are not interchangeable. ZITADEL suits cloud-native B2B identity with Terraform and organization-level multi-tenancy, Authentik suits mixed modern and legacy estates that need proxy and LDAP providers, Authelia suits reverse-proxy SSO and MFA, SuperTokens suits SDK-first application login, and Ory Hydra suits a dedicated OAuth 2.0 and OpenID Connect token service. If Keycloak authentication already works and the difficulty is fine-grained permissions, swapping identity providers will not fix it.

### Is ZITADEL a direct Keycloak replacement?

ZITADEL is a direct Keycloak replacement for many OIDC and SAML identity scenarios, particularly multi-organization B2B software that wants API-driven and Terraform-managed administration. ZITADEL can also authenticate users against an external LDAP directory. It is not a match if your applications need to bind to an LDAP endpoint served by the identity provider itself, or if you rely on Keycloak Authorization Services, so validate both requirements with a proof of concept before committing to a migration.

### Is Authentik lighter than Keycloak?

Authentik is not automatically lighter than Keycloak, and that comparison needs a benchmark rather than an assumption. Authentik proxy and LDAP provider scenarios can require separately deployed outposts, while a production Keycloak cluster needs its own database, caching, and high-availability design. Compare the two with the same user count, clients, login flows, password hashing settings, and availability target before deciding which is cheaper to operate.

### Can Authelia replace Keycloak?

Authelia can replace Keycloak only for a narrower set of use cases, specifically single sign-on, MFA, and access control in front of reverse-proxied applications. Authelia's OpenID Connect provider is OpenID Certified but its documentation still describes it as a beta feature, and its access rules operate on domains, paths, networks, and authentication level rather than on application resources. It is not a substitute for SAML support, broad identity lifecycle management, or [multi-tenant authorization](https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas) over objects such as projects and invoices.

### Does Keycloak handle fine-grained authorization?

Keycloak handles fine-grained authorization up to a point, through roles, Authorization Services, and an experimental AuthZEN evaluation endpoint added in Keycloak 26.7 behind a feature flag. Those features decide permissions from data Keycloak holds, so they work well for role and group checks. They are harder to apply when a decision depends on request-time context such as resource ownership, tenant, subscription plan, or record state, which describes most multi-tenant SaaS. That is usually the point at which teams keep Keycloak for identity and move authorization into a dedicated policy layer that supports [ABAC](https://www.cerbos.dev/blog/rbac-vs-abac).

### Can Cerbos replace Keycloak?

Cerbos cannot replace Keycloak, because the two solve different problems. Keycloak authenticates users, federates identity, and issues tokens, while Cerbos decides whether an authenticated identity may perform a given action on a given resource in the current context. They are designed to work together, and Cerbos Synapse can pull realm roles and group memberships directly from the [Keycloak Admin API](https://www.cerbos.dev/ecosystem/cerbos-keycloak-enrichment) at decision time, so policies evaluate live directory data instead of whatever was stamped into a token.