Speak at KeycloakCon Europe 2027 in Barcelona! CfP closes October 18 · Safe the date: March 15, 2027 · Submit Today →

Keycloak 26.8.0 released

October 01 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

Verifiable Credential Issuance promoted to preview with credential management and revocation

The OpenID for Verifiable Credential Issuance (OID4VCI) feature has been promoted from experimental to preview. It can now be enabled with --features=preview or --features=oid4vc-vci.

Credential lifecycle management now includes revocation when refresh tokens are revoked, and a new Application Initiated Action (AIA) lets users request credential issuance within an authenticated session. Key attestation is configurable in the admin console with hardened x5c certificate validation following the HAIP profile. This release also adds experimental support for the mdoc format, provided by the new experimental feature oid4vc-mdoc. Integration guides for the Lissi and Valera wallets are available, along with documentation for SD-JWT signing key setup, credential management, and revocation.

Example applications are provided in this release (for illustration, not officially supported):

The attestation-based client authentication (client-auth-abca), pre-authorized code grant (oid4vc-vci-preauth-code), REST credential offer endpoint (oid4vc-vci-rest-credential-offer), and OpenID4VP (oid4vc-vp) remain experimental features.

Many community members were involved in the development. Many thanks to Awambeng, Babis Routis, ShurongCAO, Pascal Knüppel, Thomas Darimont, Dominik Schlosser, forkimenjeckayang, Francis Pouatcha, Hager Khamis, Ingrid Kamga, Naman Jain, Asish Kumar, Ogen Bertrand, Hugo Hakim Damer, Rohit Behera, rameshkumarkoyya, Shashank RM, Thomas Diesler, Vinod Anandan, Palpable and Stefan Wiedemann for the contributions!

Verify credentials with OID4VP (experimental)

Organizations adopting verifiable credentials need a way to accept credential presentations from digital wallets as part of login flows, without requiring a traditional password.

Keycloak can now act as an OID4VP verifier, enabling authentication flows where users present verifiable credentials from their wallets. The verifier supports cross-device presentation flows and the direct_post.jwt encrypted response mode. Trust material for credential verification can be delegated to an external identity provider by alias, and SD-JWT User Attribute and Session mappers are available to extract claims from presented credentials.

Thanks to Dominik Schlosser for this contribution.

React to account status changes with Shared Signals Framework (experimental)

The experimental Shared Signals Framework (SSF) support now emits RISC account-disabled and account-enabled event types when a user is enabled or disabled, extending coverage beyond the CAEP session and credential events that shipped in 26.7. Additionally, the event structure has been revised for better alignment with the CAEP and RISC specifications, and the admin event store no longer receives unvalidated payloads to prevent PII leakage.

For more details, see the Shared Signals Framework guide.

Parameterized (formerly dynamic) scopes preview support (preview)

Parameterized scopes (formerly known as dynamic scopes) allow clients to pass a parameter value along with the scope name in an OAuth 2.0 authorization request. This is especially useful when a scope represents an entity with a large or dynamic set of values (for example a project name like project:12345), preventing the need to pre-define countless individual client scopes in Keycloak.

Parameterized scopes have officially moved from experimental to preview status.

For more details about the feature, see the Server Administration Guide.

Token exchange delegation with consent, FGAP authorization, and audit trail (preview)

Applications such as AI agents and automation tools need limited, consent-based access to act on behalf of a user without requiring administrator privileges or exposing sensitive credentials.

Users can now delegate access to a client application through OAuth consent using the new delegation:client:<client-id> parameterized scope. The resulting token includes an act claim identifying the client as the actor. Unlike admin-user delegation, client delegation does not grant Admin API access even if the client holds service account credentials, ensuring that a leaked delegation token cannot escalate privileges. The delegation:user and delegation:client client scopes are now auto-created as Optional scopes in all realms, and delegation authorization is controlled exclusively through Fine-Grained Admin Permissions V2 using the delegate and delegate-members scopes. Delegation audit events now include the client identity, and standard token exchange rejects subject tokens carrying delegation claims to prevent bypass. A new client policy executor allows administrators to restrict the may_act claim in access tokens, giving per-client control over which clients can participate in delegation.

Token exchange delegation support status is now preview.

For more details, see the Token exchange delegation section.

Track impersonation across token lifecycle and downstream services

When an administrator impersonates a user, downstream resource servers and audit systems had no reliable way to identify that a token was issued under impersonation or who the impersonator was.

Token lifecycle events (CODE_TO_TOKEN, REFRESH_TOKEN, and others) are now enriched with impersonator and impersonator_id details, providing a complete audit trail across all token operations performed under impersonation. Additionally, tokens issued from impersonation sessions now include the act (actor) claim (RFC 8693 Section 4.1) in both access tokens and ID tokens, allowing downstream resource servers to identify the impersonator. The claim is always present and cannot be disabled.

Secure client cluster node registration

A new client policy executor, secure-client-node-hostname, is available to protect against server-side request forgery (SSRF) via the legacy adapter cluster node registration endpoint (/clients-managements/register-node). A confidential client could previously register an attacker-chosen hostname, which Keycloak would later use as the destination for management callbacks such as logout propagation and push-revocation.

When the executor is attached to a client policy, node hostnames are validated against an administrator-configured list of regex patterns before being persisted. Registrations that do not match any pattern are rejected.

This protection is opt-in and must be explicitly configured to take effect.

Administrators managing deployments that use the legacy adapter node registration feature should add the secure-client-node-hostname executor to a client policy and configure the allowed hostname patterns. Hostname patterns match against DNS hostnames and IPv4 addresses. Port suffixes are always rejected. Patterns are matched against the bare hostname or IP address.

Administration

Declarative client management with Admin API v2 (preview)

The Client Admin API v2, introduced as an experimental feature in Keycloak 26.7, has been promoted to preview. It can now be enabled with --features=preview or --features=client-admin-api:v2.

The API provides strict validation, declarative configuration, and an accurate OpenAPI specification for managing OIDC and SAML clients. It can be consumed through a Java client, an auto-generated JavaScript client, and a CLI, and the Keycloak Operator uses it to manage clients declaratively via the KeycloakOIDCClient and KeycloakSAMLClient custom resources.

The Operator’s KeycloakOIDCClient and KeycloakSAMLClient custom resources were also promoted to Preview.

For more details, see the Admin API v2 guide and the Managing Keycloak Clients operator guide. Feedback is welcome!

Client Secret Rotation (supported)

Rotating client secrets in production without downtime required manual coordination and risked service interruptions if the old secret was invalidated before all consumers switched to the new one.

Client Secret Rotation allows confidential clients to rotate their secrets through client policies, keeping up to two concurrently active secrets for seamless rotation without downtime. Administrators can plan the rotation schedule and anticipate when applications need to adopt the new secret, reducing the risk of secret leakage.

In this release, Client Secret Rotation is promoted from preview to supported. For more details, see the Server Administration Guide.

Invite users automatically with workflows

Sending invitation emails to newly created users previously required external automation or a call to the Admin REST API’s execute-actions-email endpoint.

The new invite-user workflow step sends an action-token email automatically when a user is created, without requiring external tooling or a custom workflow step provider. Administrators can configure which required actions the user must complete (defaulting to password update and email verification), and optionally specify a client and redirect URI for the post-completion flow.

For details, see the Defining Steps guide.

Thanks to bilkoua for this contribution.

Protocol mapper allow-list for Admin REST API

Client Policies now provide the allowed-protocol-mappers executor to restrict protocol mapper types that can be created or updated through the dedicated Admin REST API protocol mapper endpoints.

SCIM API (supported)

The SCIM (System for Cross-domain Identity Management) API provides a standards-based interface for managing users and groups within a realm. It enables seamless integration with identity management systems and applications that support the SCIM protocol.

In this release, the SCIM API is promoted from preview to supported. The SCIM API received extensive improvements including support for multivalued user attributes, User Profile permissions, Fine-Grained Admin Permissions in search filters, and improved performance for large user bases. For more details, see the Managing users and groups through SCIM documentation.

Configuring and Running

Multi-cluster v2 (supported)

Multi-cluster v2 enables connecting two or more Keycloak clusters without an external Infinispan cluster by using the stateless feature. Session data is stored in the database, simplifying the deployment architecture compared to multi-cluster v1.

In this release, multi-cluster v2 and the stateless feature are promoted from preview to supported. The feature is disabled by default and can be enabled with --features=stateless. A new deployment guide for bare-metal and VM environments is now available alongside the existing Kubernetes guide. For more details, see <@links.ha id="multi-cluster-v2-introduction" />.

Multi-cluster v1 (deprecated)

Multi-cluster v1 (the multi-site feature) is deprecated and will be removed in a future major release. Multi-cluster v2, which uses the stateless feature, is the recommended replacement. It simplifies the deployment architecture by eliminating the external Infinispan cluster and its cross-site replication.

If you are using --features=multi-site, migrate to --features=stateless. For migration instructions, see Migrating from multi-cluster v1 to v2 in the High Availability Guide.

Support for encrypted PEM files for TLS certificate and private key

Deploying Keycloak with encrypted private keys previously required converting them to an unencrypted format or using a keystore, adding operational complexity.

Keycloak now supports encrypted PKCS#8 private keys in PEM format for HTTPS configuration. Use the new --https-certificate-key-file-password option to provide the decryption password. The management interface also supports this via --https-management-certificate-key-file-password. For details, see <@links.server id="enabletls"/>.

Login failures now stored in the database

Brute force detection data is now persisted in the database by default, so temporarily locked-out users remain locked out across cluster restarts. Deployments using the multi-site or clusterless features continue to store login failures in the external Infinispan cluster. The previous in-memory behavior is available as login-failures:v1 but is deprecated. For details, see the Upgrading Guide.

First-class CLI options for cluster and node name

The embedded cache cluster name and node name can now be configured with the new --cache-embedded-cluster-name and --cache-embedded-node-name CLI options, replacing the low-level SPI options that were previously required.

By default, the node name is a random value generated on each start, making it difficult to correlate metrics, logs, and JGroups diagnostics across restarts. Setting a stable node name is especially useful for observability tools such as Grafana dashboards and log aggregation.

When deploying with the Keycloak Operator, the node name is now automatically set to the Kubernetes pod name (for example, keycloak-0). For standalone deployments on Kubernetes, set KC_CACHE_EMBEDDED_NODE_NAME using the downward API to inject the pod name. For non-Kubernetes deployments, pass --cache-embedded-node-name=<name> with a value that uniquely identifies each node.

Automatic non-blocking index creation for large tables

When upgrading Keycloak with large database tables, index creation was previously skipped during schema migration to avoid blocking startup. Operators had to create the missing indexes manually.

Keycloak now automatically creates skipped indexes in the background after startup using non-blocking index creation on PostgreSQL, Oracle, MySQL/MariaDB, and supported Microsoft SQL Server editions. Invalid PostgreSQL indexes left by failed previous attempts are detected and recreated automatically. On databases without non-blocking support, Keycloak continues to log the SQL for manual execution.

Vert.x-based outbound HTTP client (experimental)

Keycloak uses the Apache HTTP Client for all outgoing connections to external services such as identity providers, OCSP responders, and backchannel logout endpoints. As Keycloak already runs on Vert.x/Netty for inbound traffic, using a separate HTTP stack for outbound connections adds unnecessary complexity and dependency overhead.

Keycloak now provides an experimental Vert.x-based HTTP client that replaces the Apache HTTP Client with Vert.x/Netty for all outgoing connections. To enable it, start Keycloak with --features=http-client:v2.

When enabled, all outgoing HTTP traffic uses the Vert.x HTTP client. Existing configuration options work the same way.

For more details, see the Configuring outgoing HTTP requests guide.

Helm Chart Operator install (experimental)

Keycloak now releases an experimental Helm chart to install the Operator.

For installation instructions, see the Operator Guide.

Organizations

Shared identity providers across organizations

Identity providers can now be linked to multiple organizations, enabling scenarios such as a single corporate identity provider serving users across different business units or subsidiaries, each represented as a separate organization. Each identity provider link carries its own auto-membership and membership type configuration, allowing fine-grained control over how users are onboarded per organization.

Domain routing has been moved from the identity provider to the domain entity. Each domain can independently specify which identity provider handles authentication and whether users are auto-redirected. The domain gate ensures cross-organization isolation — a user is only auto-added to an organization that claims their email domain, even when multiple organizations share the same identity provider.

New identity provider links created after upgrading default to the Unmanaged membership type. Existing links are migrated with the Managed type to preserve previous behavior.

For setup instructions and common configuration patterns, see Common setup recipes in the Server Administration Guide. For migration details, see the Upgrading Guide.

Themes

Redesigned identity provider buttons on the login page

The social identity provider section on the login page has been refreshed with updated icons, a new divider layout, and improved button labels.

If you have a custom login theme, see the Upgrading Guide for details on what changed.

Upgrading

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

All resolved issues

Security fixes

Weaknesses

Deprecated features

Removed features

New features

Enhancements

Bugs