Keycloak 26.4.0 released

September 30 2025

To download the release go to Keycloak downloads.

Highlights

This release features new capabilities focused on security enhancements, deeper integration, and improved server administration. The highlights of this release are:

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

Security and Standards

Passkeys integration (supported)

Passkeys are now seamlessly integrated in the Keycloak login forms using both conditional and modal UIs. To activate the integration in the realm, go to Authentication, Policies, Webauthn Passwordless Policy and switch Enable Passkeys to enabled.

For more information, see Passkeys.

FAPI 2 Final (supported)

Keycloak has support for the latest versions of FAPI 2 specifications. Specifications FAPI 2.0 Security Profile and FAPI 2.0 Message Signing are already promoted to Final and Keycloak supports them. Keycloak client policies support the final versions and corresponding client profiles for FAPI 2 are passing the FAPI conformance test suite.

Apart from some very minor polishing of existing policies, Keycloak has new client profiles (fapi-2-dpop-security-profile and fapi-2-dpop-message-signing) for the clients that use DPoP and are intended to be FAPI 2 compliant.

Thank you to Takashi Norimatsu for contributing this.

For more details, see the Securing applications Guides.

DPoP (supported)

Keycloak has support for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP), which was a preview feature since Keycloak 23. Also, the supported version includes some improvements and minor capabilities of the DPoP feature such as the following:

  • Possibility to make only refresh tokens of a public client to be DPoP bound and omit the binding of an access token.

  • All Keycloak endpoints that are secured by bearer token can now handle DPoP tokens. This includes, for example, the Admin REST API and Account REST API.

  • Possibility to require the dpop_jkt parameter in the OIDC authentication request.

Thanks to Takashi Norimatsu and Dmitry Telegin for their contributions to the DPoP feature.

For more information, see the DPoP section in the documentation.

FIPS 140-2 mode now supports EdDSA

With the upgrade to Bouncy Castle 2.1.x, the algorithm EdDSA can now be used.

Listing supported OAuth standards on one page

A new guide lists all implemented OpenID Connect related specifications. Thank you to Takashi Norimatsu for contributing this.

Integration

Federated client authentication (preview)

Identity providers are now able to federate client authentication. This allows clients to authenticate with SPIFFE JWT SVIDs, Kubernetes service account tokens, or tokens issued by an OpenID Connect identity provider.

Automatic certificate management for SAML clients

The SAML clients can now be configured to automatically download the signing and encrypting certificates from the SP entity metadata descriptor endpoint. In order to use this new feature, in the client Settings tab, section Signature and Encryption, configure the Metadata descriptor URL option (the URL where the SP metadata information with the certificates is published) and activate Use metadata descriptor URL. The certificates will be automatically downloaded and cached in the public-key-storage SPI from that URL. This also allows for seamless rotation of certificates.

For more information, see Creating a SAML client in the Server Administration Guide.

Serving as an authorization server in MCP

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems. Using MCP, AI applications can connect to data sources, tools and workflows enabling them to access key information and perform tasks.

To comply with MCP specification, this version provides its OAuth 2.0 Server Metadata via a well-known URI whose format complies with RFC 8414 OAuth 2.0 Authorization Server Metadata specification. Therefore, Keycloak users can now use Keycloak as an authorization server for MCP.

The latest MCP specification 2025-06-18 additionally requires support for resource indicators which are currently not implemented in Keycloak.

Administration

Update Email Workflow (supported)

Users can now update their email addresses in a more secure and consistent flow. Accounts are forced to both re-authenticate and verify their emails before any account updates.

For more information, see Update Email Workflow.

This feature is currently preview, and expected to become supported in 26.5.

Optional email domain for organizations

In earlier versions, each organization required at least one email domain, which was a limitation for some scenarios. Starting with this release, an email domain is optional. Thank you to Alexis Rico for contributing this.

When no domain is specified, organization members will not be validated against domain restrictions during authentication and profile validation.

Hiding identity providers from the Account Console

You can now control which identity providers appear in the Account Console based on different options using the Show in Account console setting. You can choose to show only those linked with a user or hide them completely.

For more information, see General configuration.

Enforce recovery codes setup after setting up OTP

If you have enabled OTPs and recovery codes as a second factor for authentication, you can configure the OTP required action to ask users to set up recovery codes once they set up an OTP. Thank you to Niko Köbler for contributing this.

New conditional authenticator

The Conditional - credential is a new authenticator that checks if a specific credential type has been used (or not used) during the authentication process. This condition is related to the Passkeys feature. It is added by Keycloak to the default browser flow to skip 2FA in case a passkey was used to log in as the primary credential.

For more information about conditional flows, see Conditions in conditional flows.

Translations managed by Weblate

The Keycloak distribution now includes 35 community translations, with Kazakh, Azerbaijani and Slovenian added in this release. Community volunteers now maintain some of the translations in Weblate to keep them up to date.

If you want to volunteer to maintain an existing or a new translation via Weblate, you can find the necessary steps in the translation guidelines.

Configuring and Running

Enhancements for single-cluster and multi-cluster setups

This release renamed multi-site to multi-cluster. The updated documentation describes how Keycloak clusters can be optionally distributed across multiple availability-zones within a region for increased availability. The Keycloak Operator now deploys Keycloak across multiple availability zones within a Kubernetes cluster by default. Keycloak also detects split-brains within a cluster.

This change should provide better availability for users who are running Keycloak in Kubernetes clusters that span multiple availability zones.

Support for additional databases and versions

With this release, we added support for the following new database vendors:

  • EnterpriseDB (EDB) Advanced 17.6

  • Azure SQL Database and Azure SQL Managed Instance

Where the previous documentation stated only tested database version, it now states all the supported database versions as well.

Expose management interface via HTTP

Previous versions exposed the management endpoint only via HTTPS when the main interface was using HTTPS.

Set the new option http-management-scheme to http to have the management interface use HTTP rather than inheriting the HTTPS settings of the main interface. This allows monitoring those endpoints in environments where no TLS client is available.

Expose health endpoints on the main HTTP(S) port

With health-enabled set to true, you may set the http-management-health-enabled to false to indicate that health endpoints should be exposed on the main HTTP(s) port instead of the management port. When this option is false you should block unwanted external traffic to /health at your proxy.

This allows using the health endpoints in environments where the load balancer might need access to those ports to direct traffic to the correct nodes.

Specify a tlsSecret on the Keycloak CR ingress spec

To support basic TLS termination (edge) deployments by the operator, you may now set the Keycloak CR spec.ingress.tlsSecret field to a TLS Secret name in the namespace.

Additional datasources configuration (supported)

Some Keycloak use cases like User Federation might require connecting to additional databases. This was possible only through specifying unsupported raw Quarkus properties in previous Keycloak versions. In this release, there are now dedicated server options for additional datasources. This allows users to leverage additional databases in their extensions in a supported and user-friendly way.

Read more about it in the Configure multiple datasources guide.

Observability

Operator creates a ServiceMonitor automatically

The Operator now provisions a ServiceMonitor for the management endpoint if metrics are enabled and the monitoring.coreos.com/v1:ServiceMonitor Custom Resource Definition is present on the Kubernetes cluster. The specification of the ServiceMonitor takes into account the various management endpoint configurations, to ensure that metrics can be scraped without any additional configuration. If you do not want a ServiceMonitor to be created, you can disable this by setting spec.serviceMonitor.enabled: false. For more details, see the Operator Guide.

HTTP access logging of incoming HTTP requests

Keycloak supports HTTP access logging to record details of incoming HTTP requests. While access logs are often used for debugging and traffic analysis, they are also important for security auditing and compliance monitoring.

For more information, see Configuring logging.

Showing context information in log messages (preview)

You can now add context information via the mapped diagnostic context (MDC) to each log message like the realm or the client that initiated the request. This helps you to track down a warning or error message in the log to a specific caller or environment Thank you to Björn Eickvonder for contributing this.

For more details on this opt-in feature, see Configuring logging.

Upgrading

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

All resolved issues

New features

Enhancements

Bugs