Keycloak vs Ory: which to choose for SSO

Keycloak or Ory: which fits your SSO and B2B requirements

A platform or security team choosing a self-hosted identity layer should start with one question: does the team need SAML, SCIM and organization login on day one? If it does, Keycloak fits best as a single server under Apache-2.0, because SAML 2.0, identity brokering, user federation and an admin console are in the open source distribution. Ory's open source components are also Apache-2.0, but per the Ory Kratos README, SCIM, SAML, organization login (SSO) and CAPTCHAs are enterprise features outside the open source version. For B2B SSO on Ory, the licensing conversation with Ory is part of the architecture decision, not a later detail.

The second driver is in-house UI engineering capacity. Ory Kratos is API-first and lets your team build its own login UI, with passwords, passkeys, social sign-in and TOTP available through its APIs. That suits a product team that already has frontend and identity engineers and wants full control of the login experience. A team without that capacity will spend its effort on screens and flows that Keycloak supplies with its built-in login pages and admin console. Ask who will own login UX, account recovery and error handling before choosing Ory.

The third driver is operating model. Keycloak is one server with one database, configured through its console and documented high availability designs. Ory is several services (Kratos for identities, Hydra for OAuth2 and OpenID Connect, Keto for permissions, Oathkeeper as a proxy, and Polis for SAML and SCIM single sign-on), each with its own configuration, upgrade cycle and database connections. Confirm the Ory Enterprise License scope, support SLAs and build delivery in writing with Ory before you commit, and map which of these services your team will run, patch and monitor.

Which platform fits which scenario

This table maps common identity scenarios to the platform that fits each one best, and names the condition that decides it. Read it as a shortlist filter: where a row depends on SAML, SCIM or organization login, the Ory cell assumes a paid Enterprise License build, which changes the cost and support picture.

Scenario	Better fit	Deciding condition
Workforce SSO with SAML apps	Keycloak	Keycloak includes SAML 2.0 in the Apache-2.0 server. Ory's SAML support sits in the Enterprise License builds, so open source Ory is a poor match here.
B2B SaaS with per-customer organizations	Keycloak or Ory (paid build)	Ory's organizations feature is in the Enterprise License builds. Keycloak's open source server covers multi-tenant use through realms, so choose Ory only if the paid build and its support terms fit your budget.
Custom consumer login UI	Ory	Ory Kratos is API-first and lets your team build its own login screens. Keycloak's admin console and hosted login pages suit teams that accept its default UI.
Single admin console for non-developers	Keycloak	Keycloak ships a full admin console for managing realms, clients and users. Ory's components are headless, so administration relies on APIs and your own tooling.
Kubernetes-based platform	Keycloak	The Keycloak Operator installs through Operator Lifecycle Manager or kubectl and manages Keycloak and client resources. Choose Ory when your platform team is comfortable composing several services and running its own database layer.
Own the login flow and run modular services	Ory	Kratos, Hydra and Keto can be deployed separately, which suits teams that want to replace one component at a time. This requires more integration work than a single server.
Strict upgrade downtime and CVE patch commitments	Keycloak or Ory (paid build)	Ory states that open source is not suited to deployments requiring guaranteed CVE patching or zero upgrade downtime, so confirm support terms in the Enterprise License before relying on Ory here.

How Keycloak and Ory are built and deployed

Keycloak ships as one identity server with its own admin console and database schema, while Ory splits the same job across separate services that each have their own database and release line. The sections below set out what you deploy, what you monitor and what each model asks of your operations team.

Keycloak as one server

Keycloak runs as a single server that handles OpenID Connect, OAuth 2.0 and SAML 2.0, brokers external logins, federates LDAP or Active Directory users and serves the admin console from the same process. One deployment, one upgrade path and one set of configuration cover most workforce SSO needs. Check whether your team wants the bundled console and realm model, because that is the main thing you gain by choosing this shape.

Production database requirement

Keycloak needs a relational database in production, and its default dev-file database must not be used for live traffic. Supported engines include PostgreSQL, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. Your DBA team will own backups, failover and schema sizing, so confirm that the engine you already operate is on the supported list for the Keycloak version you plan to run.

Documented high availability designs

Keycloak documents three high availability architectures: one cluster optionally spread across availability zones, multi-cluster v2 without an external Infinispan cluster, and the deprecated multi-cluster v1. Both supported designs require a synchronously replicated database, which shapes your network latency budget and your failover plan. Ask your platform team which design fits your data center layout before you choose an Ory or Keycloak topology.

Ory as separate services

Ory splits identity into Kratos for identities, Hydra for OAuth 2.0 and OpenID Connect, Keto for permissions, Oathkeeper as an identity and access proxy, and Polis for SAML and OIDC single sign-on with SCIM directory sync. You choose which services to run and wire them together through their APIs. This gives your team freedom to fit each piece to existing systems, but it also means you design the login UI, session flow and service-to-service trust yourself.

Separate databases and release lines

Each Ory service keeps its own data store and ships on its own release cadence, for example Kratos and Hydra both published v26.2.0 on March 20, 2026. Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Before you commit, confirm which database each service you need supports, and plan upgrades service by service so that a Hydra change does not block a Kratos change.

Operational load and monitoring

A single Keycloak deployment gives you one process group, one database and one upgrade to test, which keeps the monitoring surface small. An Ory stack built from several services multiplies the processes, databases, logs and version pairs you must watch, and it needs integration testing whenever one service changes. Ask whether your team can staff that operational surface and whether the Enterprise License support terms cover the components you run.

Capability comparison: Keycloak against Ory

This table sets Keycloak's all-in-one server against Ory's separate Kratos, Hydra and Keto components on the capabilities that drive a B2B SSO decision. Read each row with the license column in mind, because several SAML, SCIM and organization features sit in Ory's paid Enterprise License builds. Items marked for confirmation are areas where the supplied facts do not settle the answer.

Capability	Keycloak (Apache-2.0)	Ory open source (Apache-2.0)
Protocols	OpenID Connect, OAuth 2.0 and SAML 2.0 in the open source server	Hydra provides OAuth 2.0 and OpenID Connect; SAML requires Ory's Enterprise License or a separate component (confirm the path with Ory)
User federation from LDAP or Active Directory	Built in: reads users from LDAP or AD directories	Not a listed open source capability; confirm whether any Ory component reads an external directory
Identity brokering to external IdPs	Brokers logins to external OIDC or SAML identity providers	SSO to external providers is documented as an Enterprise License feature (Polis or Kratos path; confirm the exact component)
Admin console	Included web console for realms, clients, users and roles	No bundled admin console; administration uses APIs and the team's own tooling
Login UI model	Hosted login pages delivered by the server, with theme customization	Headless: Kratos exposes APIs so your team builds its own login UI
Database options	PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle, Aurora PostgreSQL and others; dev-file database is not for production	Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB; SQLite suits evaluation, so confirm production choices per component
Permissions model	Fine-grained authorization services inside the server	Keto is a Zanzibar-based permission server supporting ACL, RBAC and more, run as a separate service
SAML, SCIM and organization login	SAML is in the open source server; confirm which SCIM options your release provides	SAML, SCIM and organization login (SSO) are Enterprise License features per the Kratos README; Polis, which provides SAML and SCIM sync, is a separate Apache-2.0 project to evaluate

What the Apache-2.0 license and Enterprise License each cover

Keycloak is licensed under Apache-2.0, and the project publishes its community releases on GitHub and its website. The full server, including SAML 2.0, OpenID Connect, LDAP and Active Directory federation, identity brokering and the admin console, is part of that open source distribution. Red Hat build of Keycloak is a separate product: Red Hat's supported distribution based on the open source project, which replaces Red Hat Single Sign-On.

Feature set in the license: SAML 2.0 and B2B-relevant capabilities sit in the same Apache-2.0 distribution you download, with no separate enterprise build to buy for them.
Release cadence: The project plans four minor releases a year, and breaking changes in minor releases are opt-in, so you control when to adopt them.
Red Hat build as a distinct choice: Choosing the Red Hat build means buying a Red Hat subscription for support and a supported artifact, which is a different decision from the license itself.
Operator and database support: Production use requires a supported external database, and the Operator is installed through Operator Lifecycle Manager or kubectl.

Confirm with your legal and procurement teams that Apache-2.0 terms satisfy your internal policy, and confirm with Red Hat whether a subscription is needed for your support window.

How the Enterprise License changes the B2B SSO decision

For B2B single sign-on, the first question is whether SAML, SCIM and organization login must work in production on day one. Keycloak includes SAML 2.0 and brokering to external OIDC or SAML identity providers in the same server you install, and its administration covers realms and the admin console without a separate licensed build. Ory's open source components are Apache-2.0 too, but the Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features not available in the open source version. If your customers need those capabilities, the Ory Enterprise License is part of the architecture decision, not an optional extra.

Under Ory, the cost picture has more moving parts. Ory describes its Enterprise License (OEL) as optimized builds of the same open source servers, with enterprise features such as Kratos multi-tenancy and organizations, the Hydra ROPC grant, 24/7 support SLAs and timely CVE patches. Ory also says OEL builds are drop-in replacements for open source installations, which may simplify a later move onto them. Your team still runs the stack in your own environment, so you should ask Ory who carries the operating work, which components are covered, and what the support SLA and patch commitments look like in writing. Ory's Enterprise License documentation is the place to start.

Before you compare quotes, confirm the current Enterprise License scope and pricing directly with Ory, since feature lists and commercial terms can change between releases. Ask which Kratos, Hydra, Keto and Polis capabilities your B2B flows need, whether SCIM and SAML are included in the licensed build you would deploy, and what happens to your environment if the license lapses. Then map the same requirements onto Keycloak, where the SAML and organization features your team needs are part of the open source server, and price the operating effort on both sides. A DeployOpen quote would follow from a written scope covering those requirements, not from a presumed license choice.

What drives the running cost of each platform

Keycloak and Ory are both Apache-2.0 at the core, so the running cost differs less by license than by how many components you operate, what skills your team already has and whether you buy support. The cards below cover the cost drivers to examine before requesting a quote from any implementation partner.

Relational database and high availability

Keycloak needs a relational database in production, and its supported high availability designs both depend on a synchronously replicated database. Ory Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, and each Ory component manages its own data store. Ask the quote to state which database engine, backup approach and replication topology are in scope, and who operates each one after handover.

Number of services to operate

Keycloak runs as one server with its admin console, so one deployment, one upgrade path and one set of metrics cover most of the stack. Ory is a set of separate services, typically Kratos for identities, Hydra for OAuth2 and OpenID Connect, and Keto for permissions, each with its own release cycle and configuration. Count the components in your target design and ask who monitors and patches each one.

Team skills and build effort

Keycloak administration is largely configuration through the admin console, realms and the server's own APIs, with Java knowledge needed for custom extensions. Ory is API-first, so teams must build and maintain their own login and registration UI, and Go services may be needed for customization. Estimate which skills are already on staff, and ask the partner to separate front-end identity work from platform administration in any scope.

Upgrade cadence and opt-in changes

Keycloak plans four minor releases a year and says breaking changes in a minor release will be opt-in, which lowers the risk of routine upgrades but still requires testing. Each Ory component is released on its own track, so an upgrade may touch several services together. Confirm the upgrade runbook, the test environment and whether the quote covers each recurring upgrade or only the first one.

Editions and what they add

Red Hat build of Keycloak is a supported distribution of the open source project, sold through a Red Hat subscription. Ory's SCIM, SAML, organization login and CAPTCHA features sit in the Ory Enterprise License, which also carries 24/7 support SLAs and timely CVE patches. Before comparing totals, list which features your B2B SSO design needs and confirm in writing which edition or subscription includes each one.

Support and vulnerability response

Open source Keycloak and Ory are free to use, but production operators must still fund patching, monitoring and incident response. Ory states that its open source edition suits deployments that accept occasional upgrade downtime and do not require guaranteed CVE patching. Ask any quote to specify who triages CVEs, the response windows agreed in writing and whether retainer support covers upgrades between major releases.

Moving from Keycloak to Ory, or the reverse

This sequence turns a move between an admin-console IAM server and a headless, API-first stack into a set of verified, per-application cutovers. Each step ends with a check you can audit, so the migration can pause or roll back at any application boundary.

Inventory clients, protocols and user flows
Your team lists every application that depends on the source platform, the protocol each one uses (OpenID Connect, OAuth 2.0, SAML 2.0 or LDAP), the scopes and claims it reads, and the login flows it relies on, including MFA, password reset and social sign-in. Owners of each application confirm the list. Done means every application has a named owner, a protocol and a documented set of claims, and anything with no owner is parked until one is assigned.
Map realms or Ory identity schemas
Keycloak administrators map realms, roles, groups and attributes to Ory identity schemas, and Ory administrators do the reverse for Hydra clients and Keto permission models. Keycloak realms do not map one to one onto Ory concepts, so each mapping decision is written down with the reason for it. Done means a reviewed mapping document exists, and the team has agreed where Keto relations or Kratos traits replace Keycloak roles and groups.
Confirm what credentials can be exported
Security and identity engineers check whether the source platform allows password hashes, TOTP secrets and passkey credentials to leave the system in a usable form, and what the target accepts. Where export is not possible, the plan uses forced password resets or a federated bridge period instead. Confirm both export options and hash format compatibility with the vendors (Keycloak documentation and Ory documentation, or your support contacts) before scheduling any data movement. Done means a written decision per credential type, with a rollback plan for the data store.
Rebuild the login experience for the target
Keycloak ships a hosted login UI with its admin console. Ory Kratos is headless, so your team or DeployOpen builds the login, registration, recovery and MFA screens against Kratos flows and the Kratos APIs. Branding, accessibility, error handling and step-up prompts are rebuilt and tested with real user journeys. Done means every flow in the inventory has a working screen in a staging environment and a test report that covers failure paths.
Rebuild client configuration and token handling
Application teams recreate clients, redirect URIs, token lifetimes, audience and claim mappings on the target. Keycloak client settings do not translate directly into Hydra client objects, and any token customization or SAML attribute mapping is rewritten and reviewed. Keycloak's operator or configuration-as-code files, if used, are not portable and are replaced by the target's own configuration. Done means each application passes a token and claim test in staging against the documented expectations.
Run parallel logins before any cutover
Both platforms run side by side for the applications in scope, with test users and a controlled set of production users routed to the new flow. Logs, session behavior, token validity and logout are compared between the two. Confirm which vendor-supported features each side needs for production (for example, whether SAML, SCIM or organization login are in the edition you run) before relying on them. Done means parallel results match the inventory, and every discrepancy has an owner and a fix.
Cut over one application at a time
Each application moves in its own change window with a documented rollback to the source platform. Session invalidation, user communication and support scripts are agreed before the switch. Monitoring watches failed logins, token errors and support tickets for a defined observation period set by your change process. Done means each application shows successful sign-ins on the target, its old client is disabled only after the observation period, and the change record is closed.
Retire the source and keep the evidence
After the last application cuts over, the source platform is set to read-only, its data is backed up under your retention rules, and its configuration, mapping documents and test results are archived. Access reviews and audit trails are kept for the compliance evidence your assessors need. Done means the source system is decommissioned on a recorded date and the evidence pack is filed where your auditors can find it.

Where Keycloak and Ory implementation projects run long

Most of the effort in a Keycloak project sits in realm design, client and mapper configuration, and the database layer, not in installing the server. Realm boundaries decide how users, clients and identity providers are separated, and they are expensive to change once applications and brokered logins depend on them, so settle the realm model before the first production client is registered. Client scopes and protocol mappers then determine which claims or SAML attributes each application receives, and mapper mistakes often surface only when a downstream application rejects a token. For high availability, the Keycloak high availability documentation says both supported multi-site designs need a synchronously replicated database, so confirm with your database team that synchronous replication is available in your environment before you commit to an architecture. On Kubernetes, also decide the Operator update policy early. The Keycloak Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades, and a team that leaves automatic updates on will find schema and version changes arriving outside its change window.

Ory projects move the effort somewhere else. Because Kratos and Hydra are headless, your team builds the login, registration, recovery and consent screens, and it owns the security behavior of each flow, including account recovery paths and multi-factor enrollment. Hydra does not provide a consent screen of its own, so the consent flow and its acceptance and rejection handling must be wired to your user management system before any OAuth2 client can be tested end to end. The harder decision is licensing scope. The Ory Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features not available in the open source version. If your B2B product needs SAML single sign-on or SCIM provisioning for customers, the question is whether that requirement moves you onto the Ory Enterprise License, and it should be answered in writing before the design is locked. Ask Ory which exact builds and feature set your scenario requires, and ask what the Enterprise License includes for CVE patching and support, since those terms bear on your upgrade plan.

Questions buyers ask before choosing Keycloak or Ory

Do SAML and SCIM in Ory need a paid license?

Yes, in Ory's case. The Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features that are not available in the open source version. The Ory Enterprise License (OEL) provides optimized builds of the same open source servers with those features, along with 24/7 support SLAs and timely CVE patches. Keycloak, by contrast, supports SAML 2.0 under Apache-2.0 without a separate paid build. Before you design around Ory for B2B SSO, confirm in writing which exact Ory components and features your deployment needs are covered by the OEL, and ask Ory for the current terms, since editions can change.

What does the implementation work need from our own team?

Both routes need the same core inputs: a production database, a hosting platform, identity source decisions and an owner for upgrades. With Keycloak, the team typically handles a single admin console, realms, clients and federation settings. With Ory, the team also builds the login and registration UI, the flows that call Kratos and Hydra, and the authorization model in Keto if you use it. That is more application code to own and test. Ask any implementation partner to list which of these pieces are in scope, who writes and maintains the login UI, and which environments, accounts and approvals they need from you before work starts.

Can Keycloak run without Kubernetes?

Yes. Keycloak is distributed as a server that runs on virtual machines or bare metal, and it does not require Kubernetes. The Keycloak Operator is one installation route for Kubernetes and OpenShift, installed through the Operator Lifecycle Manager or with kubectl. Whichever route you choose, Keycloak needs a relational database in production, with PostgreSQL 14 to 18 among the supported options. The default dev-file database is for development only. Teams without a Kubernetes platform should plan for the database, load balancing, TLS certificates and patching on their own virtual machines, and confirm the chosen high availability design with the Keycloak documentation.

How do we confirm what the Ory Enterprise License covers?

Ask Ory for the written OEL terms and a feature list mapped to the components you plan to run, then compare that list against your requirements. Check which Kratos, Hydra and Polis features are included, how multi-tenancy and organizations are licensed, whether the Hydra ROPC grant is in scope, what support hours and CVE patch commitments apply, and how upgrades are delivered. Ory's documentation says OEL builds are drop-in replacements for open source installations, which is useful to confirm for your own version and upgrade path. Get these answers before you commit to an architecture, because they determine whether the open source components alone meet your needs.

Can our team deploy and run this without outside help?

It depends on your identity skills, your release cadence and how much custom code you need. Keycloak has a large, documented admin console and operator tooling, so a team with strong Linux, database and identity administration skills can often run it, with a plan for the upgrades Keycloak publishes four times a year. Ory asks more of your developers because the login experience and the authorization flows are code you write. A useful test is whether your team can run a restore from backup, apply a patch within your change window and explain the failure modes of each component. Where that test fails, a fixed-scope engagement or a retainer can fill the gap.

What does a DeployOpen fixed-scope engagement cover?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this comparison, that could include planning the deployment, configuring the chosen platform, integrating it with your identity sources and applications, and preparing documentation and evidence for compliance assessments. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, and it does not publish a price list, so ask for a quote based on a written scope. Ongoing support, upgrades and continuous testing are available as retainers.

How hard is it to switch from Ory to Keycloak later?

Switching is manageable when you plan for it early, and harder once users and applications are live. The main work is moving identities and credentials, re-pointing applications from Ory's APIs to Keycloak's OpenID Connect or SAML endpoints, and rebuilding any custom login flows in Keycloak's own pages or extensions. Password hashes, MFA enrollments and passkeys may not move cleanly between systems, so confirm with both vendors how they export credentials. Keep your application's authentication code behind a standard protocol layer, document your claims and roles, and test migration on a copy of production data before you commit.

How DeployOpen helps choose and implement an identity platform

DeployOpen plans, implements, integrates, hardens and documents self-hosted identity platforms inside your own cloud accounts, data centers or air-gapped networks. For Keycloak vs Ory, we start by confirming which edition and protocols your B2B SSO requirements actually need before any build work begins.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm whether you need SAML, SCIM or organization login, since these sit in Ory's Enterprise License builds.
We map your applications, login flows, user stores and database platform to the chosen architecture before quoting.

How we build

We deploy the chosen platform in your environment, with the database, network path and identity integrations set up as agreed.
We configure federation or brokering to your existing directories, and build any custom login UI if the headless option is selected.
We run security testing on the deployed identity flows and record the results against the agreed scope.

How we hand over

We document the configuration, upgrade steps, backup and restore procedures and operating runbooks for your team.
We prepare the controls and evidence your compliance assessors will ask for, without issuing any audit report or certification.
We walk your platform and security staff through administration, so they can run the system after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Retainers can cover patch planning for the platform you chose, including Ory Enterprise License CVE patching if you select it.
Ask us to confirm current release lines, edition terms and vendor support windows before each upgrade decision.

Keycloak vs Ory