Update Keycloak packages to v26.8.1 #18
Loading…
Reference in a new issue
No description provided.
Delete branch "renovate/keycloak-packages"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
26.6.0→26.8.126.6.0→26.8.1Release Notes
keycloak/keycloak (org.keycloak:keycloak-parent)
v26.8.1Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
identity-brokeringoidcidentity-brokeringadmin/fine-grained-permissionsadmin/fine-grained-permissionsauthenticationadmin/apiauthorization-servicesauthorization-servicesoidcauthenticationadmin/fine-grained-permissionsauthenticationadmin/apitoken-exchange/standardobservabilitydependenciesdependenciesauthenticationdependenciesadmin/uiadmin/apiWeaknesses
oidcorganizationsoidcauthenticationauthenticationauthenticationauthenticationidentity-brokeringoidcsamlidentity-brokeringadmin/fine-grained-permissionsstoragecoreadmin/fine-grained-permissionsBugs
admin/apitoken-exchangecoreorganizationsauthenticationauthenticationtoken-exchangeadmin/uiadmin/uiciidentity-brokeringdocsdocsdocsdocsdocsadmin/uiadmin/uicitestsuiteinfinispaninfinispanciv26.8.0Compare Source
Highlights
This release features new capabilities for users and administrators of Keycloak. The highlights of this release are:
Issue and verify digital wallet credentials with OID4VCI and OID4VP
Automate user provisioning across identity systems with the SCIM API
Run multi-cluster deployments without an external cache using stateless mode (now supported)
Simpler administration with automatic index creation, reduced memory usage, and enhanced HTTP performance
Token exchange delegation for AI agents and automation with consent and FGAP authorization
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=previewor--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):
Quickstart OID4VCI deployment - a playground for rapid prototyping with mdoc and SD-JWT credentials
OID4VCI Demo in Keycloak FAPI playground - available to show the details of the OID4VCI protocol messages exchanged between wallet and issuer, and to illustrate advanced concepts like proofs, attestation, credential refresh, and more.
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.jwtencrypted 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-disabledandaccount-enabledevent 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 anactclaim 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. Thedelegation:useranddelegation:clientclient scopes are now auto-created as Optional scopes in all realms, and delegation authorization is controlled exclusively through Fine-Grained Admin Permissions V2 using thedelegateanddelegate-membersscopes. 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 themay_actclaim 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 withimpersonatorandimpersonator_iddetails, providing a complete audit trail across all token operations performed under impersonation. Additionally, tokens issued from impersonation sessions now include theact(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-hostnameexecutor 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=previewor--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
KeycloakOIDCClientandKeycloakSAMLClientcustom resources.The Operator’s
KeycloakOIDCClientandKeycloakSAMLClientcustom 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-emailendpoint.The new
invite-userworkflow 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-mappersexecutor 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
statelessfeature. Session data is stored in the database, simplifying the deployment architecture compared to multi-cluster v1.In this release, multi-cluster v2 and the
statelessfeature 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-sitefeature) is deprecated and will be removed in a future major release. Multi-cluster v2, which uses thestatelessfeature, 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-passwordoption 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-siteorclusterlessfeatures continue to store login failures in the external Infinispan cluster. The previous in-memory behavior is available aslogin-failures:v1but 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-nameand--cache-embedded-node-nameCLI 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, setKC_CACHE_EMBEDDED_NODE_NAMEusing 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
identity-brokeringoidcauthorization-servicesdist/quarkusdist/quarkusWeaknesses
ldapsamladmin/rbacadmin/rbacadmin/apiworkflowsoidcoidcadmin/apioidcadmin/apioidcoid4vcscimscimscimadmin/api-v2admin/api-v2oid4vcoid4vcoid4vcoid4vcoid4vcoid4vcoidcdist/quarkusoid4vcoid4vcoidcscimscimscimworkflowsworkflowsscimoidcoidcstoragedist/quarkusadmin/fine-grained-permissionssamloidcadmin/apiadmin/apioidcadmin/apioidcoidcadmin/api-v2dist/quarkusoid4vcdocsoid4vcsamlauthentication/webauthnldapscimsciminfinispandocsauthenticationoid4vcoid4vcoid4vcdocsoid4vcoid4vcoid4vcadmin/api-v2scimtoken-exchangestorageoid4vcoid4vcidentity-brokeringidentity-brokeringDeprecated features
oidcoidcRemoved features
New features
ssfauthenticationEnhancements
admin/client-jstranslationssamladmin/uiadmin/uiorganizationstranslationsstorageaccount/uioidcdist/quarkusdocsidentity-brokeringdist/quarkusworkflowsobservabilityadmin/api-v2oid4vccoreworkflowslogin/uiuser-profileorganizationstoken-exchangetest-frameworkscimlogin/uioid4vclogin/uitoken-exchangecoredist/quarkusauthorization-servicessciminfinispaninfinispandist/quarkuslogin/uioidclogin/uistorageidentity-brokeringBugs
authenticationaccount/uildapdist/quarkusoid4vcoid4vcadmin/fine-grained-permissionsoidcssfstorageoid4vcauthorization-servicescoreauthorization-servicesadmin/uiauthenticationadmin/apioidcadmin/uiorganizationsstorageoidcsamladmin/uildapoid4vcadmin/clissfdist/quarkusauthenticationcorescimoidcssfdist/quarkusadmin/client-jsadmin/apiadmin/fine-grained-permissionscissfadmin/uiidentity-brokeringdocscicicicicilogin/uidist/quarkusidentity-brokeringstoragetoken-exchangeldapscimscimscimcioid4vctestsuitecisamladmin/fine-grained-permissionsciadmin/uiadmin/uiaccount/uioid4vcadmin/apidist/quarkusadmin/uidist/quarkustoken-exchangescimworkflowsaccount/uioidcadmin/uiadmin/uiciscimadmin/api-v2admin/apiauthorization-servicestestsuiteoidcauthenticationssfscimtestsuitescimaccount/uiauthenticationidentity-brokeringoid4vcoid4vcscimtranslationsscimtestsuitedist/quarkusworkflowsoperatoroid4vccoreoidcscimorganizationsauthenticationauthenticationorganizationsldapadmin/fine-grained-permissionsoid4vcadmin/apiscimscimscimadmin/uiscimscimscimadmin/uiciworkflowstestsuiteadmin/apiorganizationsoid4vcoidcadmin/uioidcoperatorauthenticationcioidcoidccorescimcoreorganizationsstoragestoragestorageidentity-brokeringauthenticationscimscimorganizationsdist/quarkustest-frameworkoperatoradmin/uiorganizationsadmin/uioidcadmin/apiauthentication/webauthnorganizationsadmin/uistorageorganizationsadmin/uidocsauthenticationorganizationsdist/quarkusssfadmin/apitoken-exchangetoken-exchangeorganizationsidentity-brokeringorganizationsidentity-brokeringadmin/uiadmin/uiorganizationsorganizationsscimv26.7.5Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
oidcoidcauthorization-servicesoidcoidcoidcsamldependenciesoidcoidcdependenciesdependenciestoken-exchangeWeaknesses
oidcEnhancements
dist/quarkusBugs
dist/quarkusauthenticationciciinfinispanoidcdist/quarkusstorageinfinispanstorageorganizationscoreorganizationscitestsuitesamltestsuitetestsuiteauthenticationtestsuitetestsuiteciadmin/uiciciauthenticationcitestsuitetestsuitecorev26.7.4Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
Enhancements
dist/quarkusBugs
dist/quarkuscidocsinfinispanadmin/apidist/quarkusadmin/uitestsuitetestsuitev26.7.3Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
ldapoidcorganizationsadmin/fine-grained-permissionsadmin/rbacoidcadmin/fine-grained-permissionsadmin/fine-grained-permissionsadmin/fine-grained-permissionsoidctoken-exchangeorganizationsoidctoken-exchangeadmin/fine-grained-permissionsauthorization-servicesoidcoidccoreoidcWeaknesses
admin/fine-grained-permissionsadmin/fine-grained-permissionsadmin/fine-grained-permissionsadmin/fine-grained-permissionsadmin/fine-grained-permissionsoidcBugs
organizationstoken-exchangecoreadmin/apiadmin/apicoredocscoreoidcciciadmin/fine-grained-permissionscoresamlcorev26.7.2Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
dependenciesadmin/fine-grained-permissionsadmin/fine-grained-permissionsoidcWeaknesses
dist/quarkusEnhancements
Bugs
authenticationscimoidcadmin/uicoreauthentication/webauthnauthenticationcoreinfinispanworkflowsdist/quarkusadmin/rbacorganizationsdocsdocsv26.7.1Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
oidcadmin/apiadmin/fine-grained-permissionsadmin/fine-grained-permissionsadmin/fine-grained-permissionsBugs
authentication/webauthncioperatorauthenticationauthenticationcorev26.7.0Compare Source
Highlights
This release features new capabilities for users and administrators of Keycloak. The highlights of this release are:
Automate user provisioning with the SCIM API (preview)
Simplified multi-cluster high availability without external caches (preview)
Enhanced reverse proxy guides with blueprints for HAProxy and Traefik
Step-up authentication for SAML clients
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
POSTand returns standard JSON responses withaccess_token,error, anderror_descriptionfields.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-abcafor 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-codeSupport 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-jwtenabled.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-apifeature.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
ssfenabled.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
authzenenabled.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
delegationparameterized 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-delegationenabled.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-samlhas 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
KeycloakOIDCClientandKeycloakSAMLClientcustom 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:v2feature.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-realmrole — 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 requiresview-usersor Fine-Grained Admin Permissions for user visibility).query-organizations— grants the ability to search and list organizations without full view access, consistent with thequery-users/query-clients/query-groupspattern.The
manage-realmrole 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_accessandresource_accesstoken claims for all group members.Additionally, the Organization Group Membership protocol mapper (OIDC and SAML) can include these roles within the
organizationclaim, 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
preferredvalue.The WebAuthn Policy and WebAuthn Passwordless Policy now provide a
Discoverable credentialoption that follows the current WebAuthn specification, supportingrequired,preferred, anddiscouragedvalues. This improves compatibility with passkey providers such as iCloud Keychain, Google Password Manager, and 1Password. The previousRequire Discoverable Credentialoption 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 (likeAcme 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:12345to request access to a particular project, oraccount:savingsto 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, andcustom(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 (preview)
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
AllNamespacesas a supported OLM install mode, allowing a single Operator instance to reconcileKeycloakcustom resources across all namespaces in the cluster. For non-OLM installations, cluster-wide deployment is available through thecluster-widekustomization 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
admin/rbacoidcoidcadmin/fine-grained-permissionsWeaknesses
identity-brokeringadmin/apioidcorganizationsorganizationsoid4vcoid4vcauthentication/webauthnauthentication/webauthnadmin/uiaccount/uissfauthenticationssfsamlsamladmin/api-v2admin/api-v2oidcRemoved features
identity-brokeringtoken-exchange/federatedNew features
operatoraccount/uiauthenticationEnhancements
testsuiteoidcadmin/uiadmin/uiadmin/uiadmin/uioidcaccount/apicoreldapauthentication/webauthnsamlorganizationsdocsoidcauthentication/webauthnlogin/uiadmin/uiauthenticationorganizationsorganizationsorganizationsauthentication/webauthnoperatordist/quarkusadmin/fine-grained-permissionsoidcorganizationsdocsorganizationsadmin/uiorganizationstranslationsdist/quarkusdist/quarkuscorecoreauthentication/webauthnauthentication/webauthnauthentication/webauthnauthentication/webauthnaccount/uiadmin/fine-grained-permissionsinfinispanssfssfdist/quarkusssflogin/uilogin/uiinfinispanorganizationstoken-exchange/subject-impersonationorganizationslogin/uidocsobservabilityoidcdocsssfdocscoreworkflowsBugs
oidcauthenticationauthorization-servicesauthenticationlogin/uicoreoidccoreaccount/uiuser-profileinfinispanaccount/uioid4vcadmin/uiauthenticationtoken-exchangeadmin/uiauthorization-servicesoidcadmin/apilogin/uiauthenticationauthenticationoidcadmin/uidist/quarkusauthenticationoid4vcauthenticationldapoid4vcauthenticationoidcciadmin/uicidependenciescioid4vcadmin/uiaccount/uidocsdist/quarkusoidcstorageadmin/uiadmin/apidist/quarkusciciciciadmin/uiadmin/apiciadmin/uidist/quarkusdist/quarkusinfinispanciciciimport-exportoidcoid4vcoid4vcadmin/uicicicicioidcciauthenticationciadmin/uicidist/quarkusorganizationsauthenticationoidcciciciciaccount/uiuser-profileadmin/apioidcadmin/uidist/quarkuscidist/quarkustestsuiteauthorization-servicesdist/quarkusstorageciorganizationssamlauthenticationadmin/apiciorganizationsstorageauthenticationoidcadmin/fine-grained-permissionsadmin/uioperatororganizationscioidcadmin/uiorganizationsadmin/uitestsuiteadmin/uiadmin/uidist/quarkusauthorization-servicesorganizationsstoragecoreadmin/uiscimauthenticationldaptestsuitessfoidcdist/quarkusidentity-brokeringdist/quarkususer-profilecoreoidcoidcdocsadmin/uiadmin/uioidcoidcadmin/client-jscoreauthorization-servicestranslationsstoragescimaccount/uiciadmin/client-jstestsuiteadmin/fine-grained-permissionsauthorization-serviceslogin/uiidentity-brokeringtestsuiteoidcdist/quarkustranslationsadmin/fine-grained-permissionsoidcstoragescimadmin/clistorageauthenticationtoken-exchangeauthenticationoidcadmin/uiscimauthenticationcoredist/quarkusorganizationsadmin/uiauthorization-servicesdocsadmin/clisamladmin/uitestsuiteldapoidcoidcauthorization-servicesauthenticationadmin/apidocsworkflowscidist/quarkusadmin/uidist/quarkusauthenticationcorev26.6.4Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
Enhancements
Bugs
cicidocsinfinispandist/quarkusv26.6.3Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
account/uioidcauthorization-servicesaccount/apioidcauthentication/webauthnadmin/fine-grained-permissionsidentity-brokeringoidcsamlorganizationsadmin/apildapoidcoidcWeaknesses
oidcauthorization-servicesauthorization-servicesauthorization-servicesEnhancements
dist/quarkusBugs
admin/uicoreauthorization-servicesoidcoidccorecorescimdocscorecorecicoreauthenticationinfinispanaccount/apildapadmin/apidist/quarkusworkflowsinfinispantestsuiteinfinispantestsuitedocsdocsdist/quarkusdist/quarkustestsuitedocsdist/quarkusadmin/apiv26.6.2Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
authorization-servicesorganizationscoreauthentication/webauthncoreEnhancements
Bugs
coreaccount/uidocsadmin/fine-grained-permissionslogin/uiadmin/fine-grained-permissionsoperatorauthenticationcoreauthenticationadmin/apiworkflowsauthenticationdocslogin/uiworkflowsciv26.6.1Compare Source
Upgrading
Before upgrading refer to the migration guide for a complete list of changes.
All resolved issues
Security fixes
corecoreEnhancements
Bugs
testsuitetestsuiteoidccioperatoradmin/client-javaadmin/client-jsadmin/uiorganizationsadmin/uiidentity-brokeringdocsdist/quarkusConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Mend Renovate CLI.
0efe1e9228dada6353a0Update Keycloak packages to v26.6.1to Update Keycloak packagesUpdate Keycloak packagesto Update Keycloak packages to v26.6.2dada6353a03420dbce3b3420dbce3b5624d45198Update Keycloak packages to v26.6.2to Update Keycloak packages5624d45198edcdb200e6Update Keycloak packagesto Update Keycloak packages to v26.6.3edcdb200e6372a08713aUpdate Keycloak packages to v26.6.3to Update Keycloak packages372a08713ab907bb5ae8Update Keycloak packagesto Update Keycloak packages to v26.6.4b907bb5ae8e8dce3f49dUpdate Keycloak packages to v26.6.4to Update Keycloak packagesUpdate Keycloak packagesto Update Keycloak packages to v26.7.0e8dce3f49df2bc46abf3f2bc46abf31ea041dc7c1ea041dc7c55794f5801Update Keycloak packages to v26.7.0to Update Keycloak packages to v26.7.1Update Keycloak packages to v26.7.1to Update Keycloak packages to v26.7.255794f5801f56bfbb03fUpdate Keycloak packages to v26.7.2to Update Keycloak packages to v26.7.3f56bfbb03febc6c137b4ebc6c137b4b50ec6da61Update Keycloak packages to v26.7.3to Update Keycloak packages to v26.7.4b50ec6da61c45ff84f8bUpdate Keycloak packages to v26.7.4to Update Keycloak packages to v26.7.5c45ff84f8bc74594ed24Update Keycloak packages to v26.7.5to Update Keycloak packages to v26.8.0c74594ed24df370ad252Update Keycloak packages to v26.8.0to Update Keycloak packages to v26.8.1View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.