Release Notes

Passkeys are now seamlessly integrated in the Red Hat build of 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.

Red Hat build of 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 Red Hat build of Keycloak supports them. Red Hat build of 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, Red Hat build of Keycloak has new client profiles (

fapi-2-dpop-security-profile

fapi-2-dpop-message-signing

For more details, see FAPI Support.

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

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

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

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

For more information, see Creating a SAML client.

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 Red Hat build of Keycloak.

Client-initiated linking a user account to the identity provider is now based on application-initiated action (AIA) implementation. This functionality aligns configuring this functionality, simplifies the error handling in calling the client application, which makes it more useful for a broader audience.

The custom protocol, which was previously used for client-initiated account linking, is now deprecated.

In previous releases, Red Hat build of Keycloak already supported federation with other OpenID Connect and SAML providers, as well as with several Social Providers like GitHub and Google, which are based on OAuth 2.0.

The new OAuth 2.0 broker now closes the gap to federate with any OAuth 2.0 provider. As a result of this change, you can federate with Amazon or other providers. As this is a generic provider, you need to specify the different claims and a user info endpoint in the provider’s configuration.

For more information, see OAuth v2 identity providers.

Until now, the OpenID Connect broker did not support the standard

email_verified

Starting with this release, Red Hat build of Keycloak supports this standard claim as defined by the OpenID Connect Core Specification for federation.

Whenever users are federated for the first time or when they re-authenticate and the Trust email setting is enabled, Sync Mode is set to

FORCE

email_verified

email_verified

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.

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.

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

You can now control which identity providers appear in the Account Console based on different options using the

Show in Account console

For more information, see General configuration.

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.

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 Red Hat build of 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.

Users can get locked out of their accounts when they lose their 2FA credentials. For example, a user may have smart phone with a one-time-password (OTP) generator as a second factor for authentication. That user might lose his phone and be locked out.

To work around this issue, users can print a set of recovery codes as an additional second factor. The recovery codes become an alternative 2FA in the login flow. As a result, the user can gain access without using the OTP generated passwords.

With this release, the recovery codes feature is promoted from preview to a supported feature. For newly created realms, the browser flow now includes the Recovery Authentication Code Form as Disabled, and it can be switched to Alternative by admins if they want to use this feature.

For more information about this 2FA method, see Recovery Codes.

Both WebAuthn Register actions (

webauthn-register

webauthn-register-passwordless

skip_if_exists

This change should make it more convenient to use the AIA in scenarios where a user has already set up WebAuthn or Passkeys. The parameter allows skipping the action if the user already has a credential of that type.

For more information, see Registering WebAuthn credentials using AIA.

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

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

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

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

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

Set the new option

http-management-scheme

http

With

health-enabled

http-management-health-enabled

false

false

/health

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.

To support basic TLS termination (edge) deployments by the operator, you may now set the Keycloak CR

spec.ingress.tlsSecret

Some Red Hat build of Keycloak use cases like User Federation might require connecting to additional databases. This was possible only through specifying unsupported raw Quarkus properties in previous Red Hat build of 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.

For more details, see Configure multiple datasources.

All available log handlers now support asynchronous logging capabilities. Asynchronous logging helps deployments that require high throughput and low latency.

For more details on this feature, see Asynchronous logging.

Red Hat build of 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 details, see HTTP Access Logging.

The time it takes to run imports, exports or migrations involving a large number of realms has been improved. A cumulative performance degradation for each additional realm processed is no longer an issue.

The Operator now includes a

ServiceMonitor

monitoring.coreos.com/v1:ServiceMonitor

ServiceMonitor

ServiceMonitor

spec.serviceMonitor.enabled: false

Red Hat build of 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.