OryvsKeycloak
A practical 2026 comparison of Ory and Keycloak for self-hosted identity: one Java server that does everything against a set of Go services you assemble, with the release cadence, authorization models and operational cost of each.
Ory
A set of independent Go services for identity, OAuth, permissions and proxying, designed to be composed. Headless by default, API first, with a managed platform in Ory Network and a commercial licence for self-hosted support.
Visit websiteKeycloak
A single Java server on Quarkus covering authentication, authorization, user federation and administration, with themeable login pages and a full admin console. CNCF incubating, with commercial support available from Red Hat.
Visit websiteBoth of these are Apache 2.0, both speak OAuth 2.0, OIDC and SAML, and both will run on your own hardware without a licence conversation. That is where the similarity ends. The two projects disagree about what an identity system is.
Keycloak is one Java service that does everything: a login page you can theme, an admin console someone can operate without writing code, LDAP and Active Directory federation, an authorization engine, and a database it expects to own. You deploy one thing and upgrade one thing. It joined the CNCF at incubating level on 10 April 2023 and ships a patch release most months, with 26.7.3 landing on 31 August 2026.
Ory is a set of separate Go services, each doing one job: Kratos for identities, credentials and sessions, Hydra for OAuth 2.0 and OIDC, Keto for relationship-based permissions, Oathkeeper as an identity-aware proxy, Polis for enterprise SAML and OIDC federation, and Talos for machine-to-machine credentials. They are single static binaries, which suits Kubernetes. Kratos is headless, so the login, recovery and verification screens are yours to build and to keep maintaining.
The choice is usually settled by two questions that have nothing to do with protocols. How much of the login experience do you want to own, and how many services do you want to upgrade? Answer those honestly and the rest follows.
Feature Comparison
| Feature | Ory | Keycloak |
|---|---|---|
| Architecture | ||
| Architecture | Separate services: Kratos, Hydra, Keto, Oathkeeper, Polis, Talos | One Java server on Quarkus that does all of it |
| Runtime and footprint | Static Go binaries, small memory footprint, container friendly | JVM on Quarkus; sized for a server rather than a sidecar |
| Extensibility | Webhooks and your own services around an API; no plugin to compile | Java service provider interfaces, themes, and JavaScript policies deployed as server extensions |
| Features | ||
| Login and recovery screens | Headless. Reference UIs exist, but production screens are yours to build and maintain | Included and themeable; login, registration, recovery and verification all ship |
| Protocols | OAuth 2.0 and OIDC in Hydra (OpenID Certified), SAML and OIDC federation through Polis | OAuth 2.0, OIDC and SAML in one server |
| Enterprise directory federation | No native LDAP or Active Directory; federation is Polis or your own code | Native LDAP and Active Directory user federation, plus identity brokering |
| Automated provisioning (SCIM) | Not a core server feature; provisioning is built against the Kratos admin API | SCIM API added in 26.7.0 with CRUD, PATCH, filtering and schema discovery, behind a preview flag |
| Machine-to-machine credentials | Talos issues and manages macaroon-based API credentials as a dedicated component | Client credentials grant, with key and secret lifecycle managed in the console |
| Operations | ||
| Admin console | API first. The finished console comes with Ory Network, not the self-hosted servers | Full web console; realms, clients and users manageable without code |
| Release cadence | Batched and infrequent: v25.4.0 in November 2024, then v26.2.0 across Kratos, Hydra and Keto on the same day in March 2026 | Monthly patches; 26.7.3 on 31 August 2026 fixed 20 security issues |
| Operational surface | One deployment and upgrade path per component you adopt, plus the frontend you wrote | One service and one database to run, back up and upgrade |
| Security | ||
| Authorization model | Keto: Zanzibar relationship tuples, strong for sharing and hierarchies, weak on request context like time of day | Authorization Services: role, group, client, time and regex policies, evaluated at the IdP without application state |
| Licensing & Governance | ||
| Licensing and governance | Apache 2.0 core, single-vendor governance, Ory Enterprise License for self-hosted support and CVE SLAs | Apache 2.0, CNCF incubating since April 2023, commercial support via Red Hat build of Keycloak |
| Cost | ||
| Managed option | Ory Network, a first-party managed platform from the same vendor | No first-party SaaS; managed Keycloak comes from Red Hat or third parties |
Architecture
Features
Operations
Security
Licensing & Governance
Cost
Pros and Cons
Strengths
- Single static Go binaries with small footprints, which suits containers and Kubernetes better than a JVM service
- Use only the parts you need: Hydra alone is a legitimate way to add OAuth to an existing identity store
- Keto implements Google's Zanzibar relationship model, which expresses sharing and hierarchy far better than roles
- Headless design means the login and recovery screens are your own code, with no theme system to fight
- Hydra is OpenID Certified, and 26.2.0 added the device authorization grant and OAuth 2.1 discovery
- Ory Talos covers machine-to-machine credentials with macaroon tokens, a problem most identity servers leave to you
Weaknesses
- You build and then maintain the login, registration, recovery and verification screens for the life of the product
- Every component is another deployment, another config file and another upgrade path
- No LDAP or Active Directory federation in the core; enterprise directories arrive through Polis or not at all
- The self-hosted open-source path has no admin console; the finished console is part of Ory Network
- Open-source releases are infrequent and batched: Kratos, Hydra and Keto all sat at v25.4.0 from November 2024 until v26.2.0 in March 2026
- Each component has its own smaller community, so answers are harder to find than for Keycloak
Strengths
- One deployment and one upgrade path for the whole identity layer
- Finished login, registration, recovery and verification pages that you theme rather than build
- A full admin console, so realms, clients and users can be managed without touching code
- Native LDAP and Active Directory federation, plus identity brokering to social and enterprise providers
- Monthly patch releases and a CNCF incubating project since April 2023, with commercial support through Red Hat
- 26.7.0 added a SCIM API in preview, closing a long-standing gap for automated provisioning and deprovisioning
Weaknesses
- A JVM service sized for a server, not a sidecar, which is heavier than a Go binary in a container-dense setup
- You adopt Keycloak's data model for users and realms whether or not it matches your application
- Authorization Services decides at the identity provider, so it cannot see your application's resource state or request context
- Major version upgrades have historically needed care and planning
- Custom logic means Java extensions or deployed JavaScript policies rather than calling an API
- Several of the newest capabilities, including SCIM, AuthZEN and Admin API v2, are preview or experimental rather than supported
Decision Matrix
Pick this if...
You need working login pages without building a frontend
The sign-in experience is part of the product design
Users live in LDAP or Active Directory
You want OAuth without adopting a new user model
Permissions are about sharing, ownership and hierarchy
Non-engineers need to administer users and clients
You run a container-dense Kubernetes platform and care about footprint
You need a predictable security patch cadence without a commercial contract
Nobody on the team owns identity infrastructure
Authorization depends on request context or resource state
Use Cases
An internal platform that has to authenticate staff against an existing Active Directory
Keycloak federates LDAP and Active Directory natively, which is a configuration screen rather than a project. Ory has no native LDAP in its core servers, so the same requirement becomes Polis or code you write and then own.
A product where the sign-in screen is part of the brand and design owns every pixel
Kratos is headless, so the screens are your components in your framework with no theme system in the way. Keycloak can be themed a long way, but you are still customising someone else's pages, and every major upgrade is a chance for that theme to need attention.
You already have a user store and only need to become an OAuth provider for third-party clients
Hydra does OAuth 2.0 and OIDC without opinions about where identities live, and it is OpenID Certified. Deploying Keycloak for this means adopting its user model as well, which is a large amount of product you did not ask for.
A small team with no one whose job is identity infrastructure
One service, one database, finished login pages and an admin console someone can operate without a deploy. The Ory path asks the same team to build a frontend and to run several services, which is more moving parts than a small team usually wants to carry.
Permissions shaped like sharing: documents, folders, teams, and users who grant access to other users
Keto implements Zanzibar relationship tuples, which is the model Google built for exactly this and which expresses inheritance and delegation directly. Keycloak's role and group policies can approximate it, but the moment a user can share their own resource with another user you are fighting the model.
Access decisions that depend on request context, such as time of day, device posture or the state of the record
Neither is a good fit and this is the honest answer. Keycloak decides at the identity provider without your application's resource state; Keto's tuples cannot express contextual conditions without denormalising them into the graph. Teams that need this usually keep either product for authentication and put a dedicated policy engine next to the application for authorization.
You need a security patch cadence you can point an auditor at
Keycloak ships patch releases roughly monthly. Ory's open-source servers went from v25.4.0 in November 2024 to v26.2.0 in March 2026, and all three moved on the same day, so the self-hosted open-source path can sit a long time between releases. Ory's answer to this is the Enterprise Licence, which sells CVE patching with an SLA, so it is a budget question rather than an impossible one.
Verdict
These are not two versions of the same product and the scores hide that. Keycloak gives you a working identity system on the first afternoon: themed login pages, an admin console, LDAP federation, one service to upgrade, and a patch most months. Ory gives you smaller pieces with clearer boundaries, a better permissions model in Keto, and a login experience that is entirely your own, in exchange for building that experience and running several services whose open-source releases can be sixteen months apart. Most teams are better served by Keycloak, and the ones who are not usually know exactly why.
Our Recommendation
Choose Keycloak for a self-hosted identity system that works out of the box, especially with enterprise directories, non-engineer administrators, or a small team. Choose Ory when the sign-in experience is part of your product, when you want one piece such as Hydra rather than the whole thing, or when your authorization is relationship shaped. If your access decisions depend on request context, keep either for authentication and put a dedicated policy engine next to your application.
Frequently Asked Questions
Related Comparisons
Found an issue?