Most comparisons of Gluu and Keycloak are years out of date, and the highest ranking one was written in 2020. The gap matters because both projects have moved since then, Gluu most visibly. New development moved to an upstream project at the Linux Foundation, the product line around it changed shape, and Keycloak rebuilt enough of its own internals that old guidance no longer always applies. If you are choosing between these two on a five year old feature grid, you are working from a picture that no longer matches either project.
There is a second reason to look again, and it is the one that outlasts the choice. Both projects now ship an authorization engine alongside the identity server. That makes this a more useful comparison than a protocol checklist, because it forces the question that decides how well either decision ages. You will know who your users are whichever you pick. What neither settles is how much visibility you have into what those users can do once a request reaches your services.
Gluu and Keycloak are not the same shape of project
Keycloak is one server. You deploy it and you get single sign-on, OpenID Connect, OAuth 2.0, SAML, an admin console, hosted login and account pages, user federation against LDAP or Active Directory, and identity brokering to social and enterprise providers. It is Apache 2.0 licensed, a Cloud Native Computing Foundation incubating project, and Red Hat maintains a supported build for organizations that want a contract behind it. The project started in 2013 and has a large community, though its internals have moved considerably, including a shift to Quarkus that changed how you configure and deploy it and the deprecation of the old client adapters.
Gluu is a company, an upstream project, and more than one product, so the name needs pinning down before the comparison means anything. The Janssen Project is the upstream open source code, chartered directly under the Linux Foundation and started as a fork of Gluu Server 4. It is a set of components rather than one binary, covering the Jans Auth Server, FIDO, SCIM, a config API, the Casa self-service portal, the Agama orchestration language, and Cedarling, its policy engine. Gluu Flex is the commercial distribution built on that upstream, adding an admin UI and support. The older Gluu Server 4 is still sold with a subscription for security updates, and its current release carries community support to December 2027 and enterprise support to December 2030, but it is in maintenance with no major features planned, so new deployments go to Janssen or Flex. Throughout this article, Gluu means the Janssen and Flex combination unless stated otherwise.
Gluu leads the upstream and sells the commercial distribution built on it. That is a closer relationship than a typical upstream and vendor split, though governance sits at the foundation rather than with the company. It also means your evaluation covers an upstream project, a distribution, and a company, where Keycloak asks you to assess one project and one roadmap.
Gluu vs Keycloak on standards depth and operational breadth
Both cover the protocols you would expect, and the checklist is worth running because it rules things out. It rarely settles the decision, because the two overlap more than the marketing on either side suggests.
The Jans Auth Server is a certified OpenID Connect provider and a complete OAuth 2.0 authorization server, and the Janssen stack implements the specifications enterprises in regulated sectors ask about, including UMA 2.0 for user managed sharing, CIBA for decoupled approval on a second device, and the financial-grade API profiles, with Gluu's Open Banking platform on the OpenID Foundation's certified FAPI provider list. Agama is the sharper differentiator, a language purpose-built for identity journeys, which is a stronger answer than Keycloak's themes and scripts when your enrollment and step-up flows involve conditional branching, multiple identity checks and step-up in a single journey.
Keycloak is not thin on these standards. Version 15.0.2 was certified as a FAPI 1.0 Advanced and Brazil Open Banking provider, it supports CIBA, and it implements UMA 2.0. Both certifications are point-in-time against specific releases on either side, so confirm the current version against the OpenID Foundation list rather than assuming it carries forward. The shortlist point stands, though. If a tender names those specifications, both projects are still in the running.
Where Keycloak went wide is operations. Federation against a directory you do not control, brokering from several external providers, and a console an operations team can run without writing code are all in the box. Realms give you a tenancy boundary without wiring it together yourself. That breadth is why it is usually the shortest path off a commercial identity contract, and our Keycloak comparison covers how it reads next to other self-hosted options, with a wider tools roundup putting both in the context of the field.
| Keycloak | Gluu (Janssen and Flex) | |
|---|---|---|
| Shape | One server | Component set plus commercial distribution |
| Governance | CNCF incubating, Red Hat build | Linux Foundation charter, Gluu lead contributor |
| Protocols | OIDC, OAuth 2.0, SAML | OIDC, OAuth 2.0, SAML |
| Regulated profiles | UMA 2.0, CIBA, FAPI certified | UMA 2.0, CIBA, financial-grade profiles |
| Directory federation | LDAP and Active Directory, brokering | SCIM, directory integration |
| Flow customization | Themes and scripting | Agama, a dedicated journey language |
| Authorization engine | Authorization Services, inside the server | Cedarling, embeddable, separate component |
| Tenancy | Realms | Assembled per deployment |
| Community size | Roughly 37,000 GitHub stars | Roughly 650 GitHub stars |
| Operational load | One deployment | Component set plus distribution choice |
Keycloak Authorization Services and Gluu's Cedarling take different designs
Keycloak has Authorization Services, a policy engine inside the identity server. You model resources and scopes on a client acting as a resource server, then write policies that are role based, group based, user based, client based, client scope based, time based, regex based, aggregated from other policies, or written in JavaScript. It supports UMA 2.0 through a Protection API and describes itself in decision point and enforcement point terms. As the authorization services guide sets out, this covers more ground than role based access alone.
Gluu went a different route with Cedarling, an embeddable policy decision point built on the Rust implementation of the Cedar policy language. It ships as a WASM package for browsers, as SDKs for Java, Go, Rust, Python and C, and as mobile bindings, and it can run embedded, as a sidecar, or as a central service. Policies live in a policy store holding the schema, the policies, and the trusted token issuers. Cedarling itself is a graduated Janssen component. Jans Lock, the enterprise packaging around it that centralizes audit logs and configuration, is still marked incubating.
The strategic difference is that Keycloak's engine is a feature of the identity server while Gluu's is a separate component that happens to come from an identity vendor. Gluu is right about the shape. A decision point that runs independently of the identity server, close to the application, is the correct design. What it does not give you is neutrality. You get one policy language, one vendor's ecosystem, and a policy distribution model tied to that ecosystem, which is a different proposition from a decision layer you could swap.
Where each engine runs out of room
The limits are practical rather than theoretical, and they are not the same on both sides.
Keycloak, the policy deployment path. The console policy types cover role, group, client, time and regex checks, which handles a great deal. Once a rule needs logic those types cannot express, you are in JavaScript, and script upload through the admin endpoints was removed in Keycloak 18, so the policy has to be deployed as a JAR file into the server. That is a reasonable security decision and an awkward operational one, because the people who understand a rule about which records a regional manager may approve are usually not the people who ship JARs into the system your entire estate authenticates against.
Cedarling, someone still has to supply the context. Cedarling never fetches data when it makes a decision, which is a deliberate and correct choice, because a decision point that queries databases on the hot path becomes both slow and unreliable. The consequence is that the caller has to assemble the context first. If that assembly lives in each application, the authorization logic you were trying to centralize ends up spread across services again, which is exactly the visibility problem an identity team is trying to solve. The question is not whether the engine is stateless. It is whether the platform gives you a governed way to build the context.
Both, a token is not a decision. Roles issued at authentication are a snapshot of what was true when the token was minted, and treating that snapshot as the access decision is a known failure pattern. The token says the user is an approver. It does not say whether this approval, on this record, at this moment, is allowed. An identity provider knows about users, groups, roles and claims. It does not know that this invoice is in draft, that this account is frozen, that this case has been sealed by legal, or that the requesting service is running in a region where the data cannot be read. Those are attributes of the resource and the request, and attribute based decisions need them at evaluation time.
That last failure has a shape identity teams recognize. Reiner Mertens of KuppingerCole made the point at EIC Berlin 2026 in a session on entitlements for APIs and microservices. A service forwards the user's token unchanged, or swaps the user's context for its own broader credentials, and the downstream system stops seeing the user and starts seeing the service. The service's permissions replace the user's, and a query returns every record the service can reach rather than the records the user should see. Neither project causes that, and neither prevents it, because it happens in code that no identity server governs.
When the AI feature on Asana's work management platform exposed data across tenants in mid 2025, roughly a thousand customers were affected by a logic flaw in the resource scoping path rather than a breach. Asana runs neither of these projects, which is the point. Login worked. Requests arrived with valid credentials. Nothing correctly checked whether the authenticated caller should see the specific resource being returned. Making that check is the job of the downstream layer, whichever project you pick.
Running a separate authorization layer behind Gluu or Keycloak
The argument for externalizing authorization is not that identity providers are bad at it. It is that authorization changes on a different clock than authentication, touches every service rather than one, and needs inputs the identity layer does not hold. The Cerbos authorization management platform is built for that position, and it does not replace your identity provider. Keycloak or the Jans Auth Server authenticates the user and issues a token. The decision point answers whether this principal may perform this action on this resource right now.
Two parts of the platform matter for the context problem above. The policy decision point, Cerbos PDP, is stateless, holding no user directory and no session state, which is what lets it run wherever needed, including as a sidecar next to every service so a check stays on localhost rather than crossing the network. Policies are written as code in YAML with conditions in CEL, versioned and reviewed like anything else in your repository, so a permission change is a reviewed pull request rather than an artifact deployed into your identity server.
The context assembly problem gets its own layer rather than being pushed back into applications. Cerbos Synapse, sits in front of the decision point and centralizes how authorization data is fetched, connecting to identity providers, databases and internal APIs with caching on the hot path. An application sends a user ID, and the data layer queries the identity provider and fetches the resource metadata before the decision is made. When you migrate to a new identity provider, that change happens once instead of in every calling service. For teams on Keycloak there is a documented integration path, with identity enrichment available through Synapse. This is the part that stays stateless on the hot path without scattering the logic.
Two properties matter for anyone whose job is governance rather than delivery. Each decision point records which policy revision decided a request, and Cerbos Hub, the managed control plane, distributes policy across your fleet and centralizes those decision logs in one place, which is what turns per-instance logs into the audit record an auditor asks for. And because the decision point speaks the OpenID AuthZEN Authorization API, which reached final specification in January 2026, the enforcement point and the decision engine do not have to come from the same vendor. You can replace the engine without rewriting every enforcement point, which is the neutrality a single vendor ecosystem cannot offer.
This holds up at real scale. Utility Warehouse, an FTSE 250 company, runs decoupled authorization across 4,500 services. The same approach covers the parts of the estate growing fastest, since service accounts, workloads and AI agents need contextual limits for the same reasons humans do, and governing non-human identities under one policy model keeps that growth inside the policy your identity team controls. It also makes authorization something you tighten as the real access pattern emerges, with every change visible, which is what treating it as a continuously governed control means in practice.
A practical way to choose
Start with what your requirements actually demand, and do not use the regulated profiles as the deciding test, because both projects cover them. Gluu is the stronger candidate when your authentication journeys are complex enough to need a dedicated language, or when you want the component level control that a set of separate services gives you. Keycloak covers more ground with less assembly when the priority is federating directories and providers you do not control and handing a console to a team that runs identity without writing code, and its community is far larger, which shows in how much troubleshooting material exists when something breaks at three in the morning. Gluu offsets that with a paid support subscription, which for some teams is the better answer than a big forum.
Then decide the governance question separately, because it outlasts the first one. Both projects will authenticate your users well. Both offer a way to keep fine-grained rules close to the identity layer, and in practice both leave you building a system where the rules that decide who sees which record are spread between an identity server, application code, and a handful of database queries. Deciding early that the runtime decision belongs in one governed layer, separate from whichever identity provider you pick, is what determines whether you can answer the question every audit and every incident review ends on. Show me the policy that was in effect at the time.
Getting started
Try Cerbos to see how a separate decision layer behaves behind an identity provider you already run, or book a call to talk through your identity and authorization split with the team.
Go deeper:
- How to adopt externalized authorization (Ebook) for a step by step playbook on moving access rules out of application code and into one governed layer
- Choosing the right authorization deployment (Guide) for a walkthrough of how to choose between deployment options
Tagged in
