Repository navigation
fix(deps): update workspace/keycloak dependencies - #11654
Open
backstage-goalie[bot] wants to merge 1 commit into
Open
backstage-goalie[bot] wants to merge 1 commit into
backstage-goalie[bot] wants to merge 1 commit into
Conversation
backstage-goalie
Bot
added
the
dependencies
backstage-goalie
Bot
requested review from
a team,
AndrienkoAleksandr,
PatAKnight,
djanickova,
dzemanov and
lholmquist
as code owners
October 21, 2026 14:38
backstage-goalie
Bot
added
the
dependencies
Signed-off-by: Renovate Bot <bot@renovateapp.com>
Contributor
Author
Changed Packages
|
backstage-service
force-pushed
the
renovate/workspace-keycloak/workspacekeycloak-dependencies
branch
from
October 21, 2026 14:41
3a6a4e8 to
f0bdbe8
Compare
Contributor
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
Collaborator
|
👋 Reminder: This Renovate patch/minor PR has been open for 7 days. Please review and merge if the changes look good. If no action is taken, this PR will be labeled |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
26.7.4→26.8.14.17.25→4.17.26Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
keycloak/keycloak (@keycloak/keycloak-admin-client)
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/webauthnldapscimsciminfinispandocsauthenticationoid4vcoid4vcoid4vcdocsoid4vcoid4vcConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate CLI.