Join us at KeycloakCon Japan 2026, colocated with KubeCon Japan 2026 · July 28 · Register Today →

Keycloak 26.7.0 released

July 09 2026

To download the release go to Keycloak downloads.

Highlights

This release features new capabilities for users and administrators of Keycloak. The highlights of this release are:

Read on to learn more about each new feature. If you are upgrading from a previous release, also review the changes listed in the upgrading guide.

Security and Standards

Stronger security for the Identity Brokering API

The Identity Brokering API allows applications to retrieve tokens obtained from external identity providers during federated login. Version 2 of this API replaces the legacy V1 with a more secure and standards-compliant design:

  • Client-level authorization — access to external tokens is controlled per client using dedicated settings (Allow retrieve external tokens and an identity provider allow list) instead of assigning broker roles to individual users.

  • Confidential clients only — public clients are rejected, ensuring that only authenticated clients can retrieve external tokens.

  • OAuth 2.0 compliant — the endpoint uses POST and returns standard JSON responses with access_token, error, and error_description fields.

  • Session-based token storage — a new Store token in session option keeps tokens in the user session for faster access, with automatic cleanup on session expiry. Database storage remains available for persistence across sessions.

V2 is now supported but disabled by default. V1 is deprecated but still enabled by default for backward compatibility. In a future release, V1 will be removed and V2 will become the default.

For more information, see the Identity Brokering APIs chapter in the Server Developer Guide.

Progress on Verifiable Credentials (OID4VCI) (experimental)

Verifiable Credentials (OID4VCI) allow organizations to issue tamper-proof, cryptographically signed credentials — such as employee badges, academic diplomas, or professional certifications — that users can store in a digital wallet and present to third parties without involving the issuer.

OID4VCI remains an experimental feature in Keycloak, but this release brings substantial improvements from both the core team and the community:

  • Polishing of existing functionality and improving configuration. Everything is now configurable in the admin UI in addition to the admin REST API.

  • Lots of bugs fixed. Improved specification compliance.

  • Conformance with the OpenID4VC High Assurance Interoperability Profile (HAIP). This work involves the introduction of the dedicated Keycloak experimental feature client-auth-abca for Attestation based client authentication (ABCA).

  • Management of verifiable credentials for individual users. This involves the ability for an administrator to create a verifiable credential for a user to indicate that this user can retrieve a verifiable credential, as well as the ability for users to start issuance of a verifiable credential from the Keycloak account console.

  • Pre-authorized code grant support is still experimental and was moved to the dedicated experimental feature oid4vc-vci-preauth-code

  • Support for credential refresh interval. Administrators can now configure a separate refresh interval (vc.refresh_interval_in_seconds) in the client scope settings that controls how often wallets must refresh the credential, independent of the credential lifetime. When not explicitly set, defaults to 7 days or the credential lifetime, whichever is smaller. This enables regular credential rotation for enhanced security while maintaining user convenience through automatic refresh using the refresh token. For more information, see the Create Client Scopes with Mappers section in the OID4VCI configuration guide.

  • Documentation updated and improved

Many community members were involved in the development. Many thanks to Awambeng, Pascal Knüppel, Dominik Schlosser, forkimenjeckayang, Ingrid Kamga, Keshav Deshpande, Naman Jain, Asish Kumar, Ogen Bertrand, Oluwatobi Mustapha, Hugo Hakim Damer, rameshkumarkoyya, Thomas Diesler and Palpable for the contributions!

Cross-domain token exchange with Identity Assertion JWT Grant (experimental)

When two organizations each run their own authorization server, users often need to re-authenticate when crossing between them — even though their identity was already verified. The Identity Assertion JWT Authorization Grant (ID-JAG) solves this by allowing one authorization server to present a signed identity assertion to another, which then issues an access token without requiring the user to log in again.

Keycloak provides partial experimental support for the Identity Assertion JWT Authorization Grant. It currently implements only the receiving authorization server role, accepting ID-JAG assertions at the token endpoint and issuing access tokens in return. Other parts of the ID-JAG specification are not yet implemented, so the complete flow is not currently supported.

To try it out, start Keycloak with the feature identity-assertion-jwt enabled.

Many thanks to Yutaka Obuchi for the contribution of this feature!

Automate user provisioning with the SCIM API (preview)

SCIM (System for Cross-domain Identity Management) is a standard protocol for reading and writing identity resources such as users and groups across multiple systems. It enables organizations to automate user provisioning and deprovisioning using widely available tooling — for example, integrating with identity governance platforms, HR systems, or other identity providers.

Keycloak has SCIM APIs for managing users and groups within a realm. The implementation covers full CRUD and PATCH operations, filtering and pagination, schema extensions including the Enterprise User extension, and schema discovery endpoints.

In this release, the SCIM API is being promoted to a preview feature. In the default profile it is disabled by default; to try it out, enable the scim-api feature.

For more details, see the Managing users and groups through SCIM documentation.

Real-time security signals to downstream applications (experimental)

When a user logs out, changes credentials, or gets disabled in Keycloak, downstream applications typically don’t learn about it until the next token refresh — leaving a window where stale sessions remain active. The OpenID Shared Signals Framework (SSF) closes this gap by letting identity providers push security events to relying parties in near real time.

Keycloak can now act as an SSF Transmitter, delivering signed Security Event Tokens (SETs) to registered receivers. It supports CAEP 1.0 and RISC 1.0 event profiles with both push (RFC 8935) and poll (RFC 8936) delivery methods. Events are persisted to a durable outbox so that no signal is lost across restarts, and a cluster-aware background drainer handles retries and exponential backoff. Each realm can opt in individually, and streams, subjects, and event types are managed through the admin console and REST API.

To enable SSF, start Keycloak with the feature ssf enabled.

For more details, see the Shared Signals Framework guide.

Standardized authorization decisions with AuthZen (experimental)

Applications that need fine-grained authorization typically call Keycloak’s proprietary authorization API, coupling them to its internal model. The OpenID AuthZEN Authorization API 1.0 defines a vendor-neutral protocol between Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs), enabling applications to request authorization decisions through a standard interface.

Keycloak now implements the AuthZEN Evaluation API as a PDP. Applications send evaluation requests describing a subject, resource, and action, and Keycloak returns a permit or deny decision based on its configured authorization policies. Both single and batch evaluation endpoints are available.

To enable AuthZen, start Keycloak with the feature authzen enabled.

For more details, see the AuthZen Authorization guide.

Authorize AI tools and MCP servers

The Model Context Protocol (MCP) is becoming the standard way for AI applications to connect to external tools and data sources. As MCP adoption grows, securing these connections with proper OAuth 2.0 authorization is critical.

Keycloak continues to improve its MCP authorization server capabilities. This release adds integration documentation for Claude Code as an MCP client, alongside the existing Visual Studio Code integration. Both use OAuth Client ID Metadata Document (CIMD) for dynamic client registration with PKCE-secured public client flows and localhost callbacks.

For setup instructions, see the Integrating with Model Context Protocol (MCP) guide.

Delegate access across services with Token Exchange Delegation (experimental)

In multi-service architectures, a backend service sometimes needs to act on behalf of a user at another service — for example, when a gateway delegates work to a downstream API. Standard Token Exchange handles client-to-client token swaps, but verifying that the requester is authorized to impersonate a specific user requires additional checks.

Keycloak introduces token exchange delegation as an experimental feature. It adds a new delegation parameterized scope type that validates whether the requesting user is authorized to act on behalf of the target user before the exchange is granted. The delegation scope requires user consent and is automatically reassessed on token refresh, so revoked impersonation rights take effect immediately.

To enable token exchange delegation, start Keycloak with the feature token-exchange-delegation enabled.

Step-up authentication for SAML clients

Step-up authentication allows applications to require a stronger level of authentication for sensitive operations. Previously, this capability was only available for OpenID Connect clients.

Keycloak now extends step-up authentication to the SAML protocol, enabling SAML service providers to request a specific authentication context class in their authentication requests. The feature step-up-authentication-saml has been promoted from preview to supported in this release.

For more information, see the Server Administration Guide.

Administration

Declarative client management with Admin API v2 (experimental)

Keycloak introduces a new REST API for managing OIDC and SAML clients. The new API provides strict validation, support for declarative configuration, and an accurate OpenAPI specification that enables reliable client generation. This addresses long-standing limitations of the original Admin REST API. This is the first resource in the Admin API v2, with additional resources to follow in future releases.

The API can be consumed through a Java client, an auto-generated JavaScript client, and a CLI. The Keycloak Operator uses it to manage clients declaratively via KeycloakOIDCClient and KeycloakSAMLClient custom resources.

Enabling this feature also enables the OpenAPI specification endpoint on the management interface, which the CLI uses to adapt its commands to the connected server version.

To try it out, enable the client-admin-api:v2 feature.

For more details, see the Admin API v2 guide and the Managing Keycloak Clients operator guide. Feedback is welcome in the Client Admin API v2 GitHub Discussion.

Thanks to Robin Meese for contributing the OpenAPI endpoint on the management interface and the Java admin client, and to Sebastian Schuster for his participation in the Admin API working group and the Go client analysis.

Fine-grained delegation for organization administration

Managing organizations in Keycloak previously required the manage-realm role — a high-privilege role that grants far more access than most organization administrators need. This release introduces dedicated admin roles and Fine-Grained Admin Permissions for organizations, allowing administrators to delegate organization management without over-provisioning access.

New realm admin roles provide coarse-grained delegation:

  • manage-organizations — grants full read and write access to organizations, including creating, updating, and deleting organizations and their members.

  • view-organizations — grants read-only access to organizations and their members (also requires view-users or Fine-Grained Admin Permissions for user visibility).

  • query-organizations — grants the ability to search and list organizations without full view access, consistent with the query-users / query-clients / query-groups pattern.

The manage-realm role continues to implicitly grant full organization management access for backward compatibility.

For per-organization granularity, organizations are now a first-class resource type in Fine-Grained Admin Permissions. Administrators can create permissions to control which specific organizations a delegated administrator can view or manage — for example, granting access to manage one organization without giving access to all organizations in the realm. When Fine-Grained Admin Permissions is enabled, organization member queries also respect user-level permissions, returning only members the administrator is permitted to view.

Automatic role inheritance through organization groups

Assigning roles to individual organization members does not scale well when an organization has hundreds of users who all need the same permissions. Organization groups now support realm and client role assignments, so administrators can assign a role once to the organization group and have it automatically appear in realm_access and resource_access token claims for all group members.

Additionally, the Organization Group Membership protocol mapper (OIDC and SAML) can include these roles within the organization claim, organized per organization, by enabling the Add group role mappings configuration option.

For more details, see the Managing organization groups guide.

Better passkey compatibility with new WebAuthn policy options

Passkeys let users sign in with biometrics or a security key instead of a password. To work correctly, the server must tell the browser whether it prefers a discoverable credential (a passkey stored on the device) or not — and the previous Yes/No option could not express the increasingly common preferred value.

The WebAuthn Policy and WebAuthn Passwordless Policy now provide a Discoverable credential option that follows the current WebAuthn specification, supporting required, preferred, and discouraged values. This improves compatibility with passkey providers such as iCloud Keychain, Google Password Manager, and 1Password. The previous Require Discoverable Credential option is now deprecated and planned for removal in a future release.

Easier realm discovery by display name search

Administrators often give realms short technical names (like acme-prod) but set a human-readable display name (like Acme Corporation). Previously, the admin console search only matched against the technical realm name, making it harder to find realms in large multi-tenant deployments.

Realm search now matches against the display name in addition to the realm name, so administrators can find realms by whichever name they remember.

Type-safe validation for parameterized scopes (experimental)

Parameterized scopes allow OAuth clients to request context-specific access — for example, project:12345 to request access to a particular project, or account:savings to scope a token to a specific bank account. Previously, the parameter value was validated only by an optional regex, making it easy to pass invalid or unexpected values.

Parameterized scopes can now define a parameter type that validates the captured value at request time. Built-in types include string, integer, boolean, username, and custom (validated against an admin-defined regex). The type is required when creating parameterized scopes with the feature enabled, ensuring that tokens always carry well-formed scope parameters.

For more details, see the Upgrading Guide.

Additional datasources may be excluded from health checks

When using multiple datasources, a failing non-critical datasource can cause the health check endpoint to report the entire deployment as unhealthy. Individual datasources can now be excluded from health checks, so optional or secondary datasources do not trigger unnecessary alerts or affect load balancer routing.

Read more about it in the Configure multiple datasources guide.

Configuring and Running

Enhanced reverse proxy guides with blueprints for HAProxy and Traefik

Running Keycloak in production requires a reverse proxy, but configuring TLS termination, certificate forwarding, and admin API security correctly across different proxies is error-prone.

The reverse proxy documentation has been significantly expanded with dedicated step-by-step guides for HAProxy and Traefik covering both TLS passthrough and re-encrypt modes, and also explain the concepts so they can be applied for other proxies as well.

For more details, see the Using a reverse proxy guide.

Simplified multi-cluster high availability without external caches (experimental)

The existing multi-cluster setup for Keycloak requires deploying and managing an external Infinispan cluster for cross-site session replication, along with vendor-specific fencing infrastructure for automated failover. This adds significant operational complexity and limits deployments to specific environments.

Multi-cluster v2 removes the external Infinispan requirement entirely. Keycloak instances connect directly to each other using embedded Infinispan caches and rely on the synchronously replicated database as the single source of truth. Cache invalidation across sites is handled through a database-backed outbox pattern. The load balancer can detect the downtime of a site without requiring external fencing infrastructure.

To enable this setup, start Keycloak with the feature stateless. For architecture details and a deployment blueprint, see the Multi-cluster deployments (v2) guide.

Keycloak Operator kustomize installation

Installing the Keycloak Operator on vanilla Kubernetes clusters previously required downloading and applying individual manifest files, making upgrades and customization harder to manage. The Operator can now be installed using kustomize, providing a declarative and reproducible installation method.

For installation instructions, see the Operator Guide.

Cluster-wide install mode for the Keycloak Operator (preview)

Organizations running multiple Keycloak instances across different Kubernetes namespaces previously needed to install a separate Operator in each namespace. The Keycloak Operator now exposes AllNamespaces as a supported OLM install mode, allowing a single Operator instance to reconcile Keycloak custom resources across all namespaces in the cluster. For non-OLM installations, cluster-wide deployment is available through the cluster-wide kustomization overlay.

Cluster-wide installation is in preview. For installation instructions and limitations, see the Operator Guide.

Upgrading

Before upgrading refer to the migration guide for a complete list of changes.

All resolved issues

Security fixes

Weaknesses

Removed features

New features

Enhancements

Bugs