Keymate vs Keycloak: what changes if you already run Keycloak
Keymate is built on Keycloak, so a team that runs Keycloak keeps its realms, clients, flows and Authorization Services. Above Keycloak, Keymate decides authorization on every request, enforces it in the request path and records what each policy version decided and any approval behind it.
When Keycloak alone is the right choice
For many teams, Keycloak alone is enough and Keymate adds nothing they need. That is the case when:
- Your access rules fit in roles, groups or Keycloak Authorization Services, and your applications are Java services that can use Keycloak's policy enforcer.
- No auditor asks you who approved a change to an access rule, or what a rule decided last March.
- You serve one organization, or a few customers whose organizations Keycloak's own organization feature already covers.
- You have people who operate Keycloak well: upgrades, patching, clustering and the container image.
If that describes you, keep running Keycloak and follow its releases.
What the free edition gives a team that runs Keycloak
Community, Keymate's free edition, includes every module for up to 100 registered users. Above 100 registered users, every module is paid, priced per user and per module, under an Enterprise agreement. Keycloak alone has no user limit. A team moving from Keycloak keeps users, organizations, federation, single sign-on, MFA and Keycloak Authorization Services. Pricing lists what each edition holds. Keymate is not open source; Keycloak underneath stays open source.
High availability, air-gapped deployment and OpenShift are in Enterprise only. Check them first if you run Keycloak clustered, offline or on OpenShift today. Enterprise is a plan for the Keymate product and includes support for it. It is not a paid edition of Keycloak.
What Keymate adds, module by module
Keycloak authenticates. Keymate decides what every identity can do, and keeps a record of each decision.
| Capability | Keycloak 26.8 | Keymate |
|---|---|---|
| Identity | ||
| User management & self-service | Yes: admin console and Account Console | Yes |
| Multi-tenant organizations / B2B tenancy | Yes: Organizations (supported since 26.0.0) | Yes: nested organizations with their own administrators |
| Delegated administration | Yes: fine-grained admin permissions (26.2.0); organization delegation since 26.7.0 | Yes: scoped administrators |
| User federation (LDAP / Active Directory) | Yes: LDAP and Active Directory federation | Yes |
| Social & enterprise IdP brokering | Yes: social, OIDC and SAML identity brokering | Yes: OIDC and SAML identity providers |
| HR-driven identity lifecycle (JML) | Partial: Workflows (supported since 26.6.0) automate lifecycle tasks; no HR connectors | Yes: API-based connectors for your HR system |
| SCIM provisioning | Yes: inbound SCIM 2.0 API, supported since 26.8.0 | Not yet |
| Authentication | ||
| SSO (OIDC, OAuth 2.1, SAML) | Yes: OIDC, OAuth 2.0 and SAML | Yes: OIDC and SAML |
| MFA & step-up | Yes: OTP, WebAuthn and step-up flows | Yes: MFA with step-up |
| Passkeys / passwordless | Yes: passkeys (supported since 26.4.0) | Yes: passkeys |
| Adaptive / risk-based access | Not documented: conditional flows only, no risk engine | Yes: risk-based MFA |
| Brute-force & account protection | Yes: brute-force detection and lockout | Yes: brute-force detection and lockout |
| Session management & token revocation | Yes: session management and token revocation | Yes: token introspection and revocation |
| Login theming & localization | Yes: themes and localization | Yes: login themes and localized flows |
| Authorization | ||
| RBAC | Yes: realm, client and composite roles | Yes |
| ABAC / policy conditions | Yes: Authorization Services policy types, including time-based and regex policies | Yes |
| ReBAC (relationship-based) | Not documented | Yes |
| Central policy engine (PBAC) for apps & APIs | Partial: Authorization Services per resource server; AuthZEN endpoint experimental since 26.7.0 | Yes: one set of policies combining role, attribute, policy, relationship and risk models |
| Risk-adaptive authorization | Not documented: no risk signals in authorization policies | Yes |
| Fine-grained PDP for APIs | Partial: Authorization Services per resource server; most client adapters deprecated | Yes |
| Per-request decisioning | Partial: where the policy enforcer is integrated | Yes: every request decided |
| Enforcement | ||
| Gateway enforcement, no app code changes | Not documented: no gateway of its own; Keycloak Gatekeeper retired in 2020 | Yes: Access Gateway, Kong and APISIX plugins, Istio and Envoy, Kafka event streams |
| Enforcement SDKs | Partial: Java policy enforcer; the Node.js adapter is deprecated | Yes: TypeScript, Java and .NET SDKs |
| Authorization Governance | ||
| Approval workflow on policy changes | Not documented: Workflows automate lifecycle tasks, not policy approval | Yes: you can require an approver |
| Policy versioning & rollback | Not documented: policies are edited in place; export and import only | Yes |
| Decision explainability (why denied) | Partial: Evaluate tab while you design policies; no reason given at runtime | Yes: the policy and condition behind each allow and deny |
| Policy change simulation | Partial: Evaluate tab simulates authorization requests against the saved policies | Yes: against past decisions |
| Decision evidence & auditor reports | Partial: login and admin events; no policy version or auditor reports | Yes: decision records with the policy version |
| Real-time decision observability | Partial: OpenTelemetry tracing; no per-decision analytics | Yes: decision stream with OpenTelemetry export |
| Audit event logging & SIEM export | Yes: login and admin events, event listener SPI, syslog output | Yes: OpenTelemetry audit pipeline |
| Identity Governance | ||
| Access certification campaigns | Not documented | Not yet |
| Segregation of duties (SoD) | Not documented | Not yet |
| End-user access request catalog | Not documented | Not yet |
| Deployment and licensing | ||
| Self-hosted on your infrastructure | Yes: self-hosted only (containers, Kubernetes Operator, ZIP) | Yes: Kubernetes on your infrastructure |
| Vendor-managed SaaS | Not documented: the project offers no hosted service | No managed service today |
| Air-gapped deployment | Partial: runs offline; no official air-gap guide | Yes (Enterprise) |
| High availability | Yes: clustering and Operator; multi-cluster v2 supported since 26.8.0 | Yes (Enterprise) |
| Pricing unit | No charge: free under the Apache License 2.0 | Per user and per module, above 100 registered users |
| Free edition | Yes: the whole project, no user limit | Free edition up to 100 registered users |
| Trial motion | Not applicable: already free | Free edition, no time limit |
| Published pricing | Not applicable: no price list | No figures at launch |
If scheduled lifecycle automation is all you need, Keycloak Workflows may already cover it. Fine-grained authorization, in depth explains the authorization models row by row. Where a Keycloak cell names a maturity (supported, preview or experimental), the label is Keycloak's own; the release status table below gives the status and first release for Workflows, SCIM, AuthZEN and the Shared Signals Framework. Keycloak release states were checked against the Keycloak 26.8.1 release notes on 17 October 2026; other Keycloak facts are from keycloak.org documentation, checked 12 and 20 October 2026. Keymate facts are from keymate.io. Spotted something out of date? Tell us and we will fix it.
Keycloak Workflows, SCIM, AuthZEN and SSF: release status
In Keycloak 26.8, Workflows and the SCIM API are supported, and AuthZEN and the Shared Signals Framework are experimental. The status labels are Keycloak's own, from its release notes.
| Keycloak feature | What it does | Status in Keycloak | Since |
|---|---|---|---|
| Workflows | Automates user and client lifecycle tasks from events, conditions and schedules | Supported | 26.6.0 (preview in 26.5.0) |
| SCIM API | Lets another system create, update and remove users in Keycloak over SCIM 2.0 | Supported | 26.8.0 (preview in 26.7.0) |
| AuthZEN | Answers authorization requests over the OpenID AuthZEN evaluation API, as a decision point | Experimental | 26.7.0 |
| Shared Signals Framework (SSF) | Sends security events, such as a session revoked or an account disabled, to downstream applications | Experimental | 26.7.0 |
Experimental and preview features are off by default and not supported for production. Preview features may still change. None of the four approves, versions or rolls back an access policy; Keymate's Authorization Governance does.
Moving your realms, clients and flows to Keymate
Keymate's identity foundation is Keycloak, so realms, clients, identity providers and authentication flows are the same objects in Keymate, not translated into another product's model. Realms, clients and flows move with Keycloak's realm export and import. keymate-migrator moves user records from another system. Keymate's build keeps Keycloak's public API and SPI contracts unchanged, so custom themes and providers written for Keycloak deploy the same way. A provider written for an older Keycloak version needs the same upgrade work it would need on Keycloak.
You do not switch over in one night. With Parallel Run, Keymate runs next to the Keycloak you operate today, applications move across one at a time, and you cut over when you are ready.
The Keycloak build Keymate ships
Keymate ships its own Keycloak build, made from source on a Chainguard Wolfi base image instead of the default Keycloak container. The image runs as a non-root user, is signed with Cosign and comes with an SBOM. Vulnerabilities in Java libraries are patched at build time without changing Keycloak's code. The Architecture page covers the build, signing and deployment on Kubernetes.
Keymate contributes to Keycloak upstream
Keymate engineers contribute fixes and features to Keycloak itself, because Keymate depends on the same project you run. Each merged change and each issue we opened is on the contributions page, drawn from the Keycloak repository.
Further reading
- Keycloak Authorization Services: how Keycloak's own engine decides permit or deny from resources, scopes, policies and permissions.
- Keycloak hardening: how we rebuilt the Keycloak container on Wolfi, with build-time patching of Java libraries, a non-root runtime and a faster startup.
Questions
Is Keymate a Keycloak alternative?
No, Keymate is not a Keycloak alternative. It is built on Keycloak and ships Keycloak as its identity foundation, so a team that chooses Keymate keeps Keycloak. Keymate adds authorization enforced in the request path, governed policy changes and organization features above it. If you are looking to move off Keycloak altogether, our IAM platform comparison covers platforms that are not based on it.
What are the limitations of Keycloak Authorization Services in production?
In Keycloak 26.x, Authorization Services edits policies in place, with no versions, approval, rollback or simulation of a change against past decisions. Its events do not record each decision with the policy version behind it. The enforcement Keycloak ships is a Java policy enforcer library, with no gateway or service-mesh enforcement point of its own. It works well for rules on roles, groups, time and resource ownership. Keymate keeps Authorization Services available, with no restriction in the free edition, and adds the missing parts; Keycloak Authorization Services explains the engine.
Who offers enterprise support for Keycloak?
Two kinds of company sell enterprise support for Keycloak: those with a supported Keycloak distribution, and those with a product built on Keycloak. Keymate is a product built on Keycloak: its Enterprise plan includes support for the Keymate product, including the Keycloak build it ships, but not for a Keycloak you run on your own. Teams that want a supported Keycloak and nothing above it need a supported distribution instead.
Is there a Keycloak enterprise edition?
No, Keycloak has no enterprise edition: it is one open-source project with no paid tier. Companies sell supported distributions of it, or products built on it: Keymate is a product built on Keycloak, with a free edition under its own license and an Enterprise plan.
How does Keymate compare to Red Hat build of Keycloak?
Red Hat build of Keycloak (RHBK) is Red Hat's supported distribution of Keycloak. Keymate is a product on its own hardened Keycloak build, with Keymate's modules on top. RHBK replaced Red Hat Single Sign-On, which left maintenance after version 7.6, so teams looking for a Red Hat SSO alternative usually meet it first. Compared with upstream Keycloak, RHBK adds a support subscription, a published lifecycle and an operator for OpenShift. If you need only a supported Keycloak on OpenShift, RHBK fits.
What are the alternatives to Red Hat build of Keycloak?
The alternatives to Red Hat build of Keycloak are upstream Keycloak that you run yourself, another supported or hosted Keycloak, a product built on Keycloak such as Keymate, or a platform not based on Keycloak. Upstream Keycloak has no license cost, and your own team carries support. A product built on Keycloak, such as Keymate, keeps your realms, clients and flows and adds modules above them. For platforms not based on Keycloak, the IAM platform comparison sets several of them side by side.