---
title: "Keycloak vs Ory"
description: "Compare Keycloak and Ory on architecture, login UI, federation and operational load, and see where each one's authorization model stops."
author: "S. B. Writer"
date: "2026-09-10T10:56:00.000Z"
canonical: "https://www.cerbos.dev/blog/keycloak-vs-ory"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Keycloak_vs_Ory_1_95d394fc8b.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/keycloak-vs-ory"
---

# Keycloak vs Ory

Keycloak and Ory come up together on almost every self-hosted identity shortlist, and the comparison is harder than it looks because the two are not really the same kind of thing. Keycloak is one server that does everything. Ory is a set of separate services you assemble into the shape you need. Both are open source, both put their core servers under Apache 2.0, and both will authenticate your users without a per-seat contract. Choosing between them is less about protocol checkboxes and more about how much of your identity stack you want to own. The authorization gap that sits on the other side of that choice is the part almost every comparison leaves out, and it is where this one spends its second half.

## Two different bets on what an identity provider should be

[Keycloak](https://www.cerbos.dev/ecosystem/cerbos-keycloak) is a Java identity and access management server, now running on Quarkus, and a Cloud Native Computing Foundation incubating project with Red Hat behind its commercial support. You deploy one service and 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. The repository dates back to 2013, which shows up in the breadth of what it covers and in the size of the community you can search when something breaks.

[Ory](https://www.cerbos.dev/ecosystem/cerbos-ory) takes the opposite bet. Instead of one server it publishes a set of single-purpose services. Ory Kratos manages identities, credentials, and sessions. Ory Hydra is an OpenID Certified OAuth 2.0 and OpenID Connect provider. Ory Keto handles permissions using a relationship model. Ory Oathkeeper is an identity aware proxy for the network edge, and Ory Polis covers enterprise SAML and OIDC single sign-on. Kratos, Hydra, Keto, and Oathkeeper are Go binaries. Polis is a TypeScript service, adopted into the project rather than built alongside the others.

The bigger difference is the login screen. Kratos is headless by design. Ory publishes reference self-service UI implementations and a component library, and its hosted Account Experience is tied to Ory Network, so the self-hosted open source path in practice means building and owning the login, recovery, and verification screens yourself. Keycloak hands you those pages finished.

That single design choice explains most of the difference in day to day experience. Keycloak gives you a working login page in an afternoon. Ory gives you total control over the login page and expects you to write it.

|  | Keycloak | Ory |
| :---- | :---- | :---- |
| **Shape** | One server | Separate services you compose |
| **Login UI** | Themeable pages included | Reference UIs, you build and own the real one |
| **Admin console** | Full web console | API first, Ory Network console for managed |
| **Enterprise federation** | LDAP, Active Directory, SAML, brokering built in | SAML and OIDC via Polis, LDAP not native |
| **Authorization model** | Authorization Services policy engine at the IdP | Keto relationship tuples, Zanzibar style |
| **Operational load** | One deployment, one upgrade path | One per component, plus your frontend |

## Where Keycloak fits best

Keycloak is the stronger pick when you want coverage without assembly. Enterprise federation is the clearest example. If you need SAML with a customer's Active Directory Federation Services, LDAP sync against a directory you do not control, and brokered logins from three different providers, Keycloak covers all of it inside one deployment with a console someone can administer without touching code. That matters when the people running identity are not the people writing the application.

Realms give you a reasonable tenancy boundary out of the box, and the admin API is comprehensive enough that you can automate most of what the console does. The maturity is real, and for teams replacing a commercial identity provider it is usually the shortest path off the contract. Our [Keycloak comparison](https://www.cerbos.dev/blog/authentik-vs-keycloak-selfhosted-idp-comparison) covers how it stacks up against other self-hosted options, and a broader [tools roundup](https://www.cerbos.dev/blog/best-open-source-auth-tools-and-software-for-enterprises-2026) puts it next to the rest of the field.

The cost is weight and opinion. It is a JVM service sized for a server rather than a sidecar, upgrades between major versions have historically needed care, and customizing the login experience means working within the theme system rather than writing your own frontend. You inherit Keycloak's data model whether or not it matches yours.

## Where Ory fits best

Ory is the stronger pick when identity is part of your product rather than infrastructure sitting beside it. Because Kratos is headless, the signup and login screens are yours. There is no theme system to work around and no hosted page you have to accept. For a consumer facing product where the first screen a user sees is a conversion surface, that control is worth real money.

The modularity also lets you take only what you need. Plenty of teams run Hydra alone because they already have a user store and only need to become an OAuth 2.0 provider for third party integrations. That is a much smaller thing to operate than a full identity server, and the equivalent with Keycloak is heavier, because becoming a token issuer means standing up the whole server even if the token endpoint was all you wanted.

The components ship as single static binaries, which suits container heavy and Kubernetes native environments. Ory also runs a managed cloud if you decide later that you do not want to operate it.

The cost is that you are the integrator. Every component you add is another deployment and another upgrade path, plus a login flow you own for the life of the product, including the recovery, verification, and multi factor screens Keycloak hands you finished. The documentation is good but the surface area is larger, and each project's community is smaller than Keycloak's single one, so obscure problems have fewer existing answers.

## The comparison that actually decides it

Protocol support rarely settles this. Both cover OAuth 2.0 and OpenID Connect properly, both reach SAML, and both federate to external providers. What settles it is who owns the login experience and how much operational surface you want.

Pick Keycloak if you want one deployment, a working admin console, deep enterprise federation, and a login page you do not have to build. Pick Ory if the login is part of your product, you want to compose only the pieces you need, and you have the engineering capacity to own the frontend and several services. A useful tie breaker is to ask who will operate this in eighteen months. A platform team with a mixed estate of internal and third party applications tends to be happier with Keycloak. A product engineering team shipping a customer facing signup flow tends to be happier with Ory.

If you are weighing other self-hosted options at the same time, our [Keycloak and ZITADEL comparison](https://www.cerbos.dev/blog/keycloak-vs-zitadel) takes a different angle on the same decision.

## Both have an authorization story, and both stop short of the same thing

This is the piece most comparisons skip, and it is the one that decides your architecture two years from now. So we want to talk about it.

Authentication answers who the user is. [Authorization](https://www.cerbos.dev/blog/authentication-vs-authorization) answers what that user, service, or agent is allowed to do once inside. Keycloak and Ory both ship something in that second category, and it is worth being precise about what each one gives you.

Keycloak has Authorization Services, a policy engine built into the server. You define resources, scopes, and permissions, then attach policies that can be role based, user based, group based, client based, time based, regex based, or aggregated from several others. There is also a JavaScript policy type, though it has to be deployed as a server extension rather than uploaded, so it is not the escape hatch it first looks like. It is a genuine policy engine and it is more capable than most people realise. The constraint is where it runs. Decisions are evaluated at the identity provider, which sees identity and its own resource definitions but not the actual row in your database, its current state, or the rest of the request context. You end up mirroring application objects into Keycloak so it has something to reason about, and keeping those two models in sync is a maintenance tax that grows with the product.

Ory Keto is a different model. It implements the Zanzibar approach, storing relationship tuples such as "this user is an editor of this document" and answering permission checks by traversing that graph. Relationship based access control is genuinely fine grained, and Keto is strong at hierarchies and sharing, where permission flows down a tree of folders or organisations, though the model is built around what an object and a subject are to each other rather than what is true at the moment of the request. Ory describes Permissions as covering RBAC and ABAC and beyond, and the graph does express a lot, but a tuple records a fact about two objects and carries no request attributes. Rules like "only during business hours", "only from a managed device", "only while the record is unlocked", or "only if the invoice total is under the approver's limit" therefore live outside it. You either denormalise those conditions into tuples, which multiplies the data you have to keep current, or you check them in application code, which is exactly the place you were trying to get that logic out of.

Both approaches also share a structural problem with roles carried in tokens. A role assigned at the identity layer tells you someone is an editor. It does not tell you whether this editor may modify this specific document, in this tenant, right now. That distinction is the difference between [role based and attribute based access control](https://www.cerbos.dev/blog/rbac-vs-abac), and it is why [stuffing more claims into the JWT](https://www.cerbos.dev/blog/easy-way-to-put-user-role-in-jwt) stops scaling once the rules depend on the resource as well as the user.

**The failure mode is real.** When the AI feature on a widely used work management platform [exposed data across tenants](https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/) between early May and early June 2025, roughly a thousand customers were potentially affected. Login was not broken. Requests arrived with valid credentials. Nothing checked whether the authenticated user should see the specific resource being returned. The gap was not the identity provider, and **no choice between Keycloak and Ory would have closed it, because nothing in either stack enforces a check the application never asks for**. That is the argument for making the decision an explicit, testable layer instead of a convention.

## How the decision layer works when it is separate

A dedicated authorization layer sits downstream of whichever identity provider you picked and answers one question per request. Can this principal perform this action on this resource, given everything that is true right now?

The [Cerbos](https://www.cerbos.dev) authorization management platform is built for that job, and the two things it does are the two things the models above cannot. First, a single rule reads token claims and resource attributes in the same expression, because policies are [YAML](https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization) with CEL (Common Expression Language) conditions evaluated where the resource actually lives. A document policy can require that the principal's Keycloak realm role is editor, that the document is not locked, that its tenant matches the principal's, and that the request falls inside working hours, in one condition that neither Keycloak's engine nor Keto can express on its own. Second, every decision is logged with the policy version that produced it, which is a level of detail an access log or a relationship change feed does not carry and is what an [auditor](https://www.cerbos.dev/blog/how-does-cerbos-help-with-compliance-audits-and-certifications) asks for.

Mechanically the [policy decision point is stateless](https://www.cerbos.dev/news/stateless-externalized-authorization-for-scalable-applications), holding no user database and no session state, so it runs as a sidecar beside each service and the check never leaves the pod. That is what makes [low latency](https://www.cerbos.dev/blog/low-latency-in-authorization) authorization practical rather than aspirational. It also speaks the [OpenID AuthZEN](https://www.cerbos.dev/authzen) standard, so it slots in as a standards-based decision point rather than a proprietary one.

[Watch on YouTube](https://www.youtube.com/watch?v=0DDin9I0abc)

For Keycloak the integration is direct. Realm roles, client roles, group memberships, and user attributes travel as principal attributes into policy evaluation, covered in our [Keycloak integration](https://www.cerbos.dev/ecosystem/cerbos-keycloak) notes. Where the token does not carry enough, Cerbos Synapse pulls the fuller profile from the Keycloak directory at decision time, including nested group paths that would never fit in a JWT. With Ory the pattern is the same, since the decision point does not care which provider minted the identity. Either way, your identity provider keeps identity and a separate layer owns the [authorization decision](https://www.cerbos.dev/blog/why-organizations-are-turning-to-decoupled-authorization-solutions), which keeps both replaceable.

## A practical way to choose

Start with the login screen, because it is the fastest way to separate these two. If you need it working next week and it can look like a login page, Keycloak. If it is part of the product and has to look like the product, Ory. Then check who operates it, since one deployment and one console is a very different commitment from several services and a frontend you maintain.

**After that, decide the authorization question deliberately rather than inheriting whatever your identity provider happens to offer.** Keycloak's policy engine and Ory's relationship model both do real work, and for coarse decisions either is fine. 

Once your rules start depending on the state of the resource and the shape of the request, plan for a separate decision layer early, because moving authorization out of an application that has grown around it is a far larger project than starting with it outside. If you want a structured way to run that evaluation, we published a [framework for it](https://www.cerbos.dev/blog/framework-evaluating-authorization-providers-solutions).

## Getting started

The fastest way to test the argument in this piece is to write one policy that reads both a token claim and a resource attribute and see whether it expresses a rule your identity provider could not. [**Try Cerbos**](https://hub.cerbos.cloud) to build and deploy that policy across your services.

If you would rather talk it through first, [book a call](https://www.cerbos.dev/workshop) with our authorization experts. For the longer version of the argument, read [already have authentication, here is the authorization layer you still need](https://www.cerbos.dev/blog/already-have-authentication-heres-the-authorization-layer-you-still-need), or take the [step by step playbook](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) for decoupling authorization from application code.

## FAQ

### What is the difference between Keycloak and Ory?

The difference between Keycloak and Ory is shape. Keycloak is one identity server that ships with an admin console, themeable login pages, user federation, and support for OpenID Connect, OAuth 2.0, and SAML in a single deployment. Ory is a set of separate services, including Kratos for identities and sessions and Hydra for OAuth 2.0, that are API first and headless, so with self-hosted Ory you build and own the login screens. Both authenticate users, and neither decides what an authenticated user may do to a specific record, which is why teams pair either one with a separate [authorization](https://www.cerbos.dev/blog/authentication-vs-authorization) layer such as the Cerbos authorization management platform.

### Should I choose Keycloak or Ory?

You should choose Keycloak if you want broad coverage from one deployment, including LDAP and Active Directory federation, SAML, and an admin console that non-developers can use, and Ory if the login screen is part of your product and you have the engineering capacity to own a frontend and several services. A useful tie breaker is who will operate it in eighteen months, since Keycloak suits a platform team and Ory suits a product engineering team. Whichever you pick, decide where authorization lives at the same time, because moving fine-grained permission checks out of an application later is a far bigger project than starting with them in a separate layer such as the Cerbos platform.

### Does Keycloak handle authorization?

Keycloak handles authorization partly, through Authorization Services, a real policy engine supporting role, user, group, client, time, regex, and aggregated policies against resources and scopes. The limit is that decisions are evaluated at the identity provider, which does not see the current state of the data your application is protecting, so teams either mirror application objects into Keycloak or move fine-grained decisions to a separate layer that runs closer to the resource. The Cerbos authorization management platform is built for that second option, evaluating Keycloak roles and resource attributes together in one policy and recording every decision for [audit](https://www.cerbos.dev/blog/why-audit-logs-are-important).

### What does Ory Keto do and what are its limits?

Ory Keto implements the Zanzibar model, storing relationships such as a user being an editor of a document and answering permission checks by traversing that graph, which suits hierarchies and sharing well. Its limit is request context, because a relationship tuple records a fact about two objects and carries no attributes of the request, so conditions like time of day, device posture, or the current status of the record end up denormalized into tuples or checked in application code. A policy based platform such as Cerbos evaluates those [attribute conditions](https://www.cerbos.dev/blog/rbac-vs-abac) alongside the relationship, so the rule lives in policy rather than in tuples or code.

### Are Keycloak and Ory free?

Yes, Keycloak and Ory are both free to self-host. Keycloak is Apache 2.0 and a Cloud Native Computing Foundation incubating project, with commercial support available from Red Hat and third parties, and Ory publishes its core servers under Apache 2.0, with some enterprise features under a separate commercial license alongside its managed cloud. The cost to plan for is not the license but the authorization logic neither one covers, which is where a dedicated platform such as Cerbos fits, so permission checks do not grow inside the application and have to be pulled out later.

### Can I use Cerbos with Keycloak or Ory?

Yes, the Cerbos authorization management platform works with Keycloak, Ory, or any other identity provider. Keycloak or Ory authenticates the user and issues a token, then Cerbos combines that identity with resource and request attributes and returns an allow or deny decision, with policies written and tested in Cerbos Hub and every decision logged for audit. 

For Keycloak, realm roles and group memberships pass into policy as principal attributes through the [Keycloak integration](https://www.cerbos.dev/ecosystem/cerbos-keycloak), and [Cerbos Synapse](https://www.cerbos.dev/ecosystem/cerbos-keycloak-enrichment) can fetch the fuller user profile from Keycloak at decision time when the token does not carry enough.