Keycloak vs Ory: Headless vs All-in-One Identity

Last updated: June 2026

Keycloak and Ory are both open-source identity projects licensed under Apache 2.0, but they represent fundamentally different philosophies: Keycloak ships as a complete, self-contained identity provider with a built-in login UI, admin console, user federation, and protocol support out of the box, while Ory is a headless, API-first collection of focused microservices — Kratos for identity and self-service flows, Hydra for OAuth2/OIDC, Keto for fine-grained permissions, and Oathkeeper as an access proxy — where your team builds the UI and assembles the pieces. Choose Keycloak when you need a batteries-included platform to go live quickly; choose Ory when you want composable, cloud-native building blocks and are willing to invest the engineering time to wire them together and own the user-facing experience.

Philosophy and Architecture

The single biggest difference is not a feature list — it is the mental model each project asks you to adopt.

Keycloak treats identity as a product: download the JAR or container image, configure a realm, and you have a working login page, registration flow, admin console, user management UI, and SAML/OIDC/LDAP federation. Engineers can start authenticating real users within hours. The trade-off is that you are working within Keycloak’s model. Customization happens through themes, SPIs (Service Provider Interfaces), and authentication flow configuration — powerful, but bounded by what the platform exposes.

Ory treats identity as infrastructure: a set of HTTP APIs your application calls. There is no bundled UI. Kratos exposes REST and gRPC endpoints for registration, login, recovery, and settings; your frontend calls those endpoints and renders whatever experience you design. Hydra issues OAuth2 and OIDC tokens but has no user store of its own — it delegates identity to an external system (typically Kratos). Keto evaluates permissions using a Zanzibar-style relationship model. Oathkeeper acts as a reverse proxy or decision API that enforces access policies before requests reach your upstream services.

Dimension	Keycloak	Ory
Architecture	Monolithic IdP (all-in-one)	Composable microservices
Philosophy	Batteries-included platform	API-first building blocks
Login UI	Built-in (themeable)	None — build your own
Admin console	Full web UI	API-only (Ory Network UI for cloud)
User store	Built-in, plus federation	Kratos manages identities
Primary language	Java (Quarkus, as of v17+)	Go
License	Apache 2.0	Apache 2.0
Managed offering	Skycloak, others	Ory Network

Ory’s Component Stack

Because Ory is composed of four distinct projects, it helps to understand what each one does and what it does not do.

Ory Kratos — Identity Management

Kratos handles the self-service identity flows: registration, login, account recovery, email verification, settings management, and multi-factor authentication. It is schema-driven — you define what fields an identity carries (email, name, custom traits) in a JSON schema and Kratos enforces it. Kratos exposes two APIs: a public API your frontend calls, and an admin API for backend operations.

Kratos does not issue OAuth2 tokens. It manages identities and sessions; token issuance is Hydra’s job.

Ory Hydra — OAuth2 and OIDC

Hydra is a certified OAuth2 and OpenID Connect provider. It handles authorization code flows, client credentials, device authorization, token introspection, and JWKS endpoints. Hydra is deliberately stateless with respect to identities: it has no user database. When a user needs to authenticate during an OAuth2 flow, Hydra redirects to a “login and consent app” that you build (often backed by Kratos). After the user authenticates, your app tells Hydra the outcome and Hydra issues tokens.

This separation is architecturally clean but requires explicit integration work. Compare this with Keycloak, where the authorization server and the user store are the same system and the login UI is already provided.

Ory Keto — Permissions

Keto implements the Zanzibar authorization model originally developed by Google. Permissions are expressed as relationship tuples: document:readme#viewer@user:alice means Alice has the viewer relation on the readme document. Keto’s check API answers whether a given subject has a given relation to a given object, traversing the relationship graph as needed.

This model is expressive for hierarchical or graph-based authorization — file systems, team memberships, document sharing — but requires you to populate the relationship store and design your namespace schema.

Keycloak’s equivalent is the Authorization Services feature (UMA 2.0, policy-based ABAC/RBAC). It is less flexible for arbitrary relationship graphs but integrates directly with Keycloak’s client model and requires no separate service. For a deeper look at what Keycloak’s authorization engine can do, see Fine-Grained Authorization in Keycloak Explained.

Ory Oathkeeper — Access Proxy

Oathkeeper is a reverse proxy and decision API. It evaluates rules against incoming requests — checking session cookies, verifying JWTs, calling Keto for permission checks — and either forwards the request to the upstream or rejects it. It sits in front of your services as a zero-trust enforcement point.

Keycloak covers similar ground through its adapter libraries, the OAuth2 Proxy pattern, or Keycloak’s built-in gateway integrations, but there is no direct equivalent to Oathkeeper as a standalone component.

Protocol and Standards Support

Protocol / Standard	Keycloak	Ory Hydra
OAuth 2.0	Yes	Yes (certified)
OpenID Connect 1.0	Yes (certified)	Yes (certified)
SAML 2.0	Yes	No
LDAP / Active Directory	Yes (federation)	No (Kratos only, no LDAP)
SCIM 2.0	Yes (via Skycloak / extensions)	No native support
WebAuthn / Passkeys	Yes	Yes (via Kratos)
Device Authorization Grant	Yes	Yes
PKCE	Yes	Yes
DPoP	Yes (26.x)	Partial
Token Exchange	Yes	No

SAML support is a meaningful gap for Ory in enterprise environments. If you need to federate with enterprise identity providers over SAML — common in healthcare, finance, and large enterprise scenarios — Keycloak handles this natively. For a broader comparison of open-source identity platforms and their protocol coverage, see the Open Source Authentication Comparison 2026.

Login UI and Self-Service Flows

This is where the architectural difference hits hardest in practice.

Keycloak ships with a complete, themeable login UI. You can customize it using FreeMarker templates and CSS within Keycloak’s theme system, or use dynamic client-initiated backchannel authentication. The registration flow, password reset, MFA enrollment, and account management console all work out of the box. Most teams can go live without writing any frontend authentication code.

Ory ships with no login UI whatsoever. The Ory Network (cloud product) provides a default UI for evaluation, but in a self-hosted deployment you are responsible for every pixel of the login experience. Kratos gives you the API; you write the React, Vue, or server-rendered HTML. This is a feature if you need total UI control — no more wrestling with FreeMarker. It is a significant up-front investment if you want to ship quickly.

Capability	Keycloak	Ory
Default login page	Yes	No
Themeable UI	Yes (FreeMarker + CSS)	N/A — you own the UI
Account management console	Yes	No (build your own)
Registration flow	Built-in, configurable	Kratos API + your UI
Password reset	Built-in	Kratos API + your UI
MFA enrollment	Built-in	Kratos API + your UI
Social login	Built-in (20+ providers)	Kratos (limited providers)

Permissions Model

Aspect	Keycloak Authorization Services	Ory Keto
Model	RBAC, ABAC, UMA 2.0, policy-based	Zanzibar relationship tuples
Storage	Internal (Keycloak DB)	Separate Keto service + DB
API	REST (token introspection, RPT)	REST / gRPC check API
Use case fit	Role-based access with resource scopes	Hierarchical / graph-based ACLs
Admin UI	Yes (Keycloak admin console)	API-only
Audit	Keycloak event log	External logging

Keto’s Zanzibar model shines for Google Docs-style sharing, where permissions flow through relationships (user is member of group, group has editor access to folder, folder contains document). If your access model is primarily role-based — user has role X, role X grants action Y — Keycloak Authorization Services is more direct and requires fewer moving parts.

Deployment and Operational Effort

Keycloak

Self-hosting Keycloak 26.x means running a Quarkus-based Java application with a relational database backend (PostgreSQL recommended). For production you will configure clustering (Infinispan distributed cache), set up database connection pooling, tune JVM memory, configure reverse proxy headers, and manage TLS termination. The operational surface is real but well-documented and covered by a large community.

The biggest Keycloak operational complaint is not complexity but maintenance: upgrades between major versions can involve schema migrations and breaking changes in SPIs or themes. Teams that are not primarily in the Java ecosystem sometimes find the JVM tuning unfamiliar.

That is where managed Keycloak removes friction entirely. Skycloak handles provisioning, upgrades, clustering, backups, and monitoring so your team focuses on configuration and integration rather than operations.

Ory

Self-hosting the full Ory stack means running four separate services (Kratos, Hydra, Keto, Oathkeeper), each with its own database schema, configuration file, migration tooling, and release cadence. You also need to build and host the login/consent UI application. The individual services are lightweight Go binaries — resource usage per container is lower than Keycloak — but the total operational footprint across four services plus your own UI service is significant.

Ory Network (Ory’s cloud product) removes the self-hosting burden and provides a managed API-first identity platform, but at that point you are paying for a SaaS offering rather than the open-source economics of self-hosting.

Effort Dimension	Keycloak (self-hosted)	Ory (self-hosted)
Services to operate	1 (+ DB)	4+ (+ DB per service + UI app)
UI work required	Minimal (theme customization)	Significant (build from scratch)
Time to first working login	Hours	Days to weeks
Upgrade complexity	Medium (major version migrations)	Medium (four independent release cycles)
Community size	Very large	Smaller but active
Documentation quality	Comprehensive	Good, but spread across four projects
Managed option	Skycloak, others	Ory Network

When to Choose Keycloak

Keycloak is the right choice when:

• You need SAML 2.0 support for enterprise integrations, healthcare, or finance.
• You want a working login UI without building one yourself.
• Your team needs an admin console for non-developer operators to manage users, roles, and clients.
• You are federating existing LDAP or Active Directory user stores.
• You need SCIM provisioning for enterprise user lifecycle management.
• You want a large community, extensive documentation, and broad ecosystem support.
• You want to move from an expensive commercial IdP without a full custom-build effort.

For a head-to-head against another popular open-source identity platform, see Keycloak vs FusionAuth.

When to Choose Ory

Ory is the right choice when:

• You need total control over the login UI and user experience — no theme customization limits.
• Your architecture is already microservices-first and you want identity components that fit the same pattern.
• You need Zanzibar-style relationship-based permissions (Keto) that are difficult to express in Keycloak’s policy model.
• Your team has Go expertise and values lightweight, stateless services over a heavier JVM-based monolith.
• You do not need SAML (your integrations are OAuth2/OIDC only).
• Your team is willing to invest weeks of engineering time to assemble, integrate, and maintain the full stack.

OAuth2 and OIDC: How They Compare

Both Keycloak and Ory Hydra are certified OpenID Connect providers. The token formats, grant types, and OIDC Discovery endpoints work the same way from a client’s perspective. For a developer-focused walkthrough of the underlying protocol, see the OAuth 2.0 Developer’s Visual Guide.

The integration difference is in the login flow. In Keycloak, the authorization endpoint redirects users to Keycloak’s built-in login page. In Hydra, the authorization endpoint redirects to your own login application — which calls Kratos, authenticates the user, then calls Hydra’s accept API to complete the flow. The end result is standards-compliant OAuth2 either way, but the assembly effort for Hydra is substantially higher.

Frequently asked questions

Is Ory a Keycloak alternative?

Ory and Keycloak solve overlapping problems — both provide OAuth2/OIDC, identity management, and authorization — but they are not drop-in alternatives for each other. Keycloak is a self-contained identity provider: you configure it and it handles login, user storage, and token issuance. Ory is a set of API-first components you assemble yourself and integrate with your own login UI. Migrating from Keycloak to Ory (or vice versa) requires re-architecting how your application handles authentication flows, not just swapping a configuration file. They are alternatives in the sense that both can satisfy an OAuth2/OIDC requirement, but the engineering investment to reach that point differs substantially.

Does Ory have a login UI?

Ory does not ship a login UI in its open-source components. Kratos exposes HTTP APIs for registration, login, recovery, and settings flows, but your team is responsible for building the frontend that calls those APIs. The Ory Network (the managed cloud product) provides a default UI for getting started, but it is not available to self-hosted deployments. This is a deliberate design choice: Ory believes teams should own their UX completely. It is an asset if UI flexibility is critical; it is a meaningful time cost if you need to go live quickly.

Keycloak vs Ory Hydra: what is the difference?

Keycloak and Ory Hydra are not direct equivalents. Hydra is specifically an OAuth2 authorization server — it issues tokens, manages clients and scopes, and implements the OIDC provider spec, but it has no user store of its own. Keycloak is a complete identity provider that includes an authorization server, user management, login UI, admin console, and federation. When people compare “Keycloak vs Hydra,” they are usually comparing Keycloak to the combination of Hydra plus Kratos (identity) plus your custom login application — which is roughly equivalent in scope to Keycloak’s feature set, but assembled from separate components.

Does Ory support SAML?

Ory does not support SAML 2.0 in any of its core components. Hydra is an OAuth2/OIDC provider only; Kratos handles self-service identity flows over HTTP but does not implement SAML assertions. If your organization needs to integrate with enterprise SAML identity providers (ADFS, Okta, corporate SSO) or act as a SAML identity provider itself, Keycloak is the appropriate choice. SAML remains a hard requirement in many regulated industries, and this is one of the clearest decision points between the two platforms.

Can I use Ory Keto with Keycloak?

Yes, in principle. Keto is a standalone permissions service with an HTTP/gRPC API. There is nothing technically preventing you from using Keycloak for authentication and token issuance while calling Keto for fine-grained permission checks in your application backend. Some teams take this approach when they want Keycloak’s mature IdP capabilities alongside Keto’s Zanzibar-style permission model, which Keycloak’s own Authorization Services does not replicate exactly. The integration requires your application to call both systems: Keycloak for token validation and Keto for permission evaluation. For teams who want to stay within a single platform, Keycloak’s Authorization Services handles most RBAC and ABAC patterns without an additional service. See Fine-Grained Authorization in Keycloak Explained for details on what Keycloak’s built-in authorization engine can handle.

Conclusion

Keycloak and Ory represent two valid but very different answers to the question of how to add identity to your platform.

Keycloak gives you a complete, production-ready identity provider from day one. Login UI, admin console, user federation, SAML, SCIM — it is all there, configured rather than coded. The operational cost is real, but it is the cost of running one well-understood service. For most teams that want mature open-source identity without building from scratch, Keycloak is the pragmatic choice.

Ory gives you composable identity primitives. If you need total UI ownership, Zanzibar-style permissions, or a microservices-native identity layer and your team has the engineering capacity to assemble and operate the stack, Ory’s design is genuinely elegant. The headless approach is not a limitation — it is the product.

The difference comes down to what you are optimizing for: speed and completeness (Keycloak), or composability and UI control (Ory). Neither is wrong. Both are open source, actively maintained, and production-proven.

If you want Keycloak’s batteries-included power without the operational overhead of running it yourself, Skycloak provides managed Keycloak hosting with automated upgrades, clustering, backups, and monitoring — so you get the full Keycloak feature set without managing the infrastructure.

For more comparisons in this space, see What Is Keycloak? A Complete Guide and the Open Source Authentication Comparison 2026.