This release contains the fix of the important security issue affecting some OIDC confidential clients using PAR (Pushed authorization request). In case you use OIDC confidential clients together with PAR and you use client authentication based on client_id and client_secret sent as parameters in the HTTP request body (method client_secret_post specified in the OIDC specification), it is highly encouraged to rotate the client secrets of your clients after upgrading to this version.

When updating user attributes through the Admin User API, you cannot execute partial updates when updating the user attributes, including the root attributes like username , email , firstName , and lastName .

Due to an issue in the release process when deploying Keycloak using the Operator it installed the nightly container instead of 24.0.0 .

As a quick fix to the issue, the 24.0.0 container was tagged with nightly , and the nightly releases was temporarily disabled.

If you installed or upgraded to 24.0.0 using the Operator before 5pm CET yesterday the database may have been updated with the wrong versions. To check if you are affected connect to your database and run the following SQL command:

SELECT * from migration_model WHERE version = '999.0.0';

If the above returns a matching row you will need to take some actions, otherwise database migrations will not run for future releases. To resolve this run the following SQL command:

UPDATE migration_model SET version = '24.0.0' WHERE version = '999.0.0';

The user profile preview feature is promoted to be fully supported and user profile is enabled by default.

In the past months, the Keycloak team spent a huge amount of effort in polishing the user profile feature to make it fully supported. In this release, we continued the effort. Lots of improvements, fixes and polishing were done based on the thorough testing and feedback from our awesome community.

The following are a few highlights of this feature;

Fine-grained control over the attributes that users and administrators can manage so that you can prevent unexpected attributes and values from being set.

Ability to specify what user attributes are managed and should be displayed on the forms to regular users or administrators.

Dynamic forms - Previously, the forms where users created or updated their profiles, contain four basic attributes like username, email, first name and last name. The addition of any attributes (or removing some default attributes) required you to create a custom theme. Now custom themes may not be needed because users see exactly the requested attributes based on the requirement of the particular deployment.

Validations - Ability to specify validators for the user attributes including built-in validators that you can use to specify a maximum or minimum length, a specific regex, or limiting a particular attribute to be a URL or number.

Annotations - Ability to specify that particular attribute should be rendered for instance as a text area, an HTML select with specified options, or calendar or many other options. You can also bind JavaScript code to a specific field to change how an attribute is rendered and customize its behavior.

Progressive profiling - Ability to specify that some fields are required or available on the forms just for particular values of scope parameter. This effectively allow progressive profiling. You no longer need to ask the user for twenty attributes during registration; you can instead ask the user to fill in attributes incrementally according to the requirements of the individual client applications that are used by the user.

In this release, the following templates were updated to make it possible to dynamically render attributes based on the user profile configuration set to a realm:

In this release, the server renders the update profile page when the user is authenticating through a broker for the first time using the idp-review-user-profile.ftl template.

Jetty 9.4 has not been supported in the community for a long time, and reached end-of-life in 2022. At the same time the adapter has not been updated or tested with more recent versions of Jetty. For these reasons the Jetty adapter has been removed from this release.

We introduced version 3 of the Account Console in Keycloak 22 as a preview feature. In this release, we are making it the default version, and deprecating version 2 in the process, which will be removed in a subsequent release.

This new version has built-in support for the user profile feature, which allows administrators to configure which attributes are available to users in the Account Console, and lands a user directly on their personal account page after logging in.

This release contains support for Lightweight access tokens. As a result, you can have smaller access tokens for specified clients. These tokens have only a few claims, which is why they are smaller. Note that lightweight access token is still JWT signed by the realm key by default and still contains some very basic claims.

This release introduces an Add to lightweight access token flag that is available on some OIDC protocol mappers. Use this flag to specify if a particular claim should be added to a lightweight access token. It is OFF by default, which means that most claims are not added.

Also, a client policy executor exists. Use it to specify if a particular client request should use lightweight access tokens or regular access tokens. An alternative to the executor is to use an Always use lightweight access token flag on client advanced settings, which causes that client to always use lightweight access tokens. An executor can be an alternative if you need more flexibility. For instance, you may choose to use lightweight access tokens by default but use regular tokens only for the specified scope parameter.

A previous release added an Add to token introspection switch. You use it to add claims that are not present in the access token into the introspection endpoint response.

Features now support versioning. To preserve backward compatibility, all existing features (including account2 and account3 ) are marked as version 1. Newly introduced features will use versioning, which means that users can select between different implementations of desired features.

You may also take advantage of the new server-side handling of truststores by using the Keycloak CR, for example:

spec:
  truststores:
    mystore:
      secret:
        name: mystore-secret
    myotherstore:
      secret:
        name: myotherstore-secret

Currently only Secrets are supported.

The cert for the Kubernetes CA is added automatically to your Keycloak Pods managed by the Operator.

The SAML identity providers can now be configured to automatically download the signing certificates from the IDP entity metadata descriptor endpoint. In order to use the new feature, configure the Metadata descriptor URL option in the provider (the URL where the IDP metadata information with the certificates is published) and set Use metadata descriptor URL to ON . The certificates are automatically downloaded and cached in the public-key-storage SPI from that URL. The certificates can also be reloaded or imported from the Admin Console, using the action combo in the provider page.

A new health check endpoint available at /lb-check was added. The execution is running in the event loop, which means this check is responsive also in overloaded situations when Keycloak needs to handle many requests waiting in request queue. This behavior is useful, for example, in multi-site deployment to avoid failing over to another site that is under heavy load. The endpoint is currently checking availability of the embedded and external Infinispan caches. Other checks may be added later.

The Keycloak CR now includes an startOptimized field, which may be used to override the default assumption about whether to use the --optimized flag for the start command. As a result, you can use the CR to configure build time options also when a custom Keycloak image is used.

In this release, we are encapsulating the root user attributes (such as username , email , firstName , lastName , and locale ) by moving them to a base/abstract class in order to align how these attributes are marshalled and unmarshalled when using both Admin and Account REST APIs.

This strategy provides consistency in how attributes are managed by clients and makes sure they conform to the user profile configuration set to a realm.

Starting with this release, the first member of a Keycloak cluster will load remote sessions sequentially instead of in parallel. If offline session preloading is enabled, those will be loaded sequentially as well.

In this release, you can no longer perform actions such as email verification if the user is already authenticated and the action is bound to another user. For instance, a user can not complete the verification email flow if the email link is bound to a different account.

In this release, if a user tries to follow the link to verify the email and the email was previously verified, a proper message will be shown.

In addition to that, a new error ( EMAIL_ALREADY_VERIFIED ) event will be fired to indicate an attempt to verify an already verified email. You can use this event to track possible attempts to hijack user accounts in case the link has leaked or to alert users if they do not recognize the action.

The default behavior of Keycloak is to load offline sessions on demand. The old behavior to preload them at startup is now deprecated, as pre-loading them at startup does not scale well with a growing number of sessions, and increases Keycloak memory usage. The old behavior will be removed in a future release.

To reduce memory requirements, we introduced a configuration option to shorten lifespan for offline sessions imported into the Infinispan caches. Currently, the offline session lifespan override is disabled by default.

When enabling metrics for Keycloak’s embedded caches, the metrics now use labels for the cache manager and the cache names.

As of this release, Keycloak supports storing and searching by user attribute values longer than 255 characters, which was previously a limitation.

There have been a couple of enhancements to the Brute Protection:

When an attempt to authenticate with an OTP or Recovery Code fails due to Brute Force Protection the active Authentication Session is invalidated. Any further attempts to authenticate with that session will fail.

In previous versions of Keycloak, the administrator had to choose between disabling users temporarily or permanently due to a Brute Force attack on their accounts. The administrator can now permanently disable a user after a given number of temporary lockouts.

The property failedLoginNotBefore has been added to the brute-force/users/{userId} endpoint

In previous versions of Keycloak, when the last member of a User, Group or Client policy was deleted then that policy would also be deleted. Unfortunately this could lead to an escalation of privileges if the policy was used in an aggregate policy. To avoid privilege escalation the effect policies are no longer deleted and an administrator will need to update those policies.

The Keycloak CR now allows for specifying the cache-config-file option by using the cache spec configMapFile field, for example:

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  cache:
    configMapFile:
      name: my-configmap




    

      key: config.xml

The Keycloak CR now allows for specifying the resources options for managing compute resources for the Keycloak container. It provides the ability to request and limit resources independently for the main Keycloak deployment via the Keycloak CR, and for the realm import Job via the Realm Import CR.

When no values are specified, the default requests memory is set to 1700MiB , and the limits memory is set to 2GiB .

You can specify your custom values based on your requirements as follows:

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  resources:
    requests:
      cpu: 1200m
      memory: 896Mi
    limits:
      cpu: 6
      memory: 3Gi

There is now a new event USER_DISABLED_BY_TEMPORARY_LOCKOUT when a user is temporarily locked out by the brute force protector. The log with ID KC-SERVICES0053 has been removed as the new event offers the information in a structured form.

Cookie handling code has been refactored and improved, including a new Cookie Provider. This provides better consistency for cookies handled by Keycloak, and the ability to introduce configuration options around cookies if needed.

User Attribute Mapper For NameID allowed setting Name ID Format option to the following values:

However, Keycloak does not support receiving AuthnRequest document with one of these NameIDPolicy , therefore these mappers would never be used. The supported options were updated to only include the following Name ID Formats:

Instead of specifying hardcoded values for the initial and maximum heap size, Keycloak uses relative values to the total memory of a container. The JVM options -Xms and -Xmx were replaced by -XX:InitialRAMPercentage and -XX:MaxRAMPercentage .

Deploying Keycloak to multiple independent sites is essential for some environments to provide high availability and a speedy recovery from failures. This release supports active-passive deployments for Keycloak.

This release addresses an issue concerning when a user has a login page open in multiple browser tabs and authenticated in one browser tab. When the user tries to authenticate in another browser tab, a message appears: You are already logged-in . This is improved now as other browser tabs automatically authenticate the user after authentication in the first tab. However, more improvements are still needed. For example, when an authentication session expires and is restarted in one browser tab, other browser tabs do not follow automatically with the login.

Deploying Keycloak to multiple independent sites is essential for some environments to provide high availability and a speedy recovery from failures. This release adds preview-support for active-passive deployments for Keycloak.

OpenID Connect adapter for WildFly and JBoss EAP, which was deprecated in previous versions, has been removed in this release. It is being replaced by the Elytron OIDC adapter,which is included in WildFly, and provides a seamless migration from Keycloak adapters.

The SAML adapter for WildFly and JBoss EAP is no longer distributed as a ZIP download, but rather a Galleon feature pack, making it easier and more seamless to install.

Keycloak has switched to RESTEasy Reactive. Applications using quarkus-resteasy-reactive should still benefit from a better startup time, runtime performance, and memory footprint, even though not using reactive style/semantics. SPIs that depend directly on JAX-RS API should be compatible with this change. SPIs that depend on RESTEasy Classic including ResteasyClientBuilder will not be compatible and will require an update. This update will also be needed for other implementation of the JAX-RS API like Jersey.

Message properties files for themes are now read in UTF-8 encoding, with an automatic fallback to ISO-8859-1 encoding.

See the migration guide for more details.

The Map Store has been an experimental feature in previous releases. Starting with this release, it is removed and users should continue to use the current JPA store. See the migration guide for details.

A security vulnerability was introduced in Keycloak 22.0.2. We highly recommend not upgrading to 22.0.2, and for anyone that has deployed 22.0.2 in production to upgrade to 22.0.3 immediately.

For users that has self-registered after Keycloak was upgraded to 22.0.2 their password is not stored securely, and can be exposed to administrators of Keycloak. This only affects users that has registered after the upgrade was rolled-out, and does not affect any previously registered users.

Any realm using the preview declarative user profile is not affected by this issue, and only realms using the default user profile provider is affected.

To identify if there are any affected users in your deployment you can query these by accessing the database, and running the following SQL statement:

SELECT DISTINCT U.ID, U.USERNAME, U.EMAIL, U.REALM_ID FROM USER_ENTITY U
    INNER JOIN USER_ATTRIBUTE UA ON U.ID = UA.USER_ID
    WHERE UA.NAME IN ('password','password-confirm')

We recommend contacting any affected users as well as adding the update password required action for them.

If there are any affected users we also recommend removing these attributes from the database by running the following SQL statement:

DELETE FROM USER_ATTRIBUTE UA WHERE UA.NAME IN ('password','password-confirm')

If any backups have been done of the database after the 22.0.2 release and there are affected users, we recommend deleting these.

Any deployments with custom user storage federation providers may also be affected if the provider is delegating to Keycloak storing user attributes, please verify your custom user storage to identify if this is an issue.

To identify if there are any federated user affected in your deployment, you can query these by accessing the database, and running the following SQL statement:

SELECT DISTINCT USER_ID,REALM_ID,STORAGE_PROVIDER_ID FROM FED_USER_ATTRIBUTE
    WHERE NAME IN ('password','password-confirm')

If there are any affected federated users, we also recommend removing these attributes from the database by running the following SQL statement:

DELETE FROM FED_USER_ATTRIBUTE UA WHERE UA.NAME IN ('password','password-confirm')

If your custom user storage provider is managing attributes itself, you should look at your custom storage to remove the password and password-confirm attributes.

Keycloak now supports multiple LDAP providers in a realm, which support Kerberos integration with the same Kerberos realm. When an LDAP provider is not able to find the user which was authenticated through Kerberos/SPNEGO, Keycloak ties to fallback to the next LDAP provider. Keycloak has also better support for the case when single LDAP provider supports multiple Kerberos realms, which are in trust with each other.

Keycloak upgraded to version 3.2.0.Final of the Quarkus Java framework. Quarkus 3.x continues the tradition of propelling Java development by moving fast and providing a cutting-edge user experience with the latest technologies.

As part of upgrading to Quarkus 3.x Keycloak migrated its codebase from Java EE (Enterprise Edition) to its successor Jakarta EE, which brings various changes into Keycloak. We have upgraded all Jakarta EE specifications in order to support Jakarta EE 10.

In order to provide a better runtime and leverage as much as possible the underlying stack, all injection points for contextual data using the javax.ws.rs.core.Context annotation were removed. The expected improvement in performance involves no longer creating proxies instances multiple times during the request lifecycle, and drastically reducing the amount of reflection code at runtime.

As a number of users have had problems with configuring the hostname for the server correctly there is now a new helper tool to allow debugging the configuration.

Installations which use Keycloak’s --proxy configuration setting with mode passthrough should review the documentation as the behavior of this mode has changed.

In previous releases, the export and import commands required a build command to be run first. Starting with this release, the export and import commands perform an automatic rebuild of Keycloak if a build time configuration has changed.

The old Account Console (v1) is now completely removed. This version of the Account Console was marked as deprecated in Keycloak 12.

In version 21.1.0 of Keycloak the new Account Console (version 3) was introduced as an experimental feature. Starting this version it has been promoted to a preview feature.

Two of the variables exposed to the Account Console V2 and V3 templates ( isEventsEnabled and isTotpConfigured ) were left unused, and have been removed in this release.

It is possible that if a developer extended the Account Console theme, he or she could make use of these variables. So make sure that these variables are no longer used if you are extending the base theme.

After the upgrade to Jakarta EE, artifacts for Keycloak Admin clients were renamed to more descriptive names with consideration for long-term maintainability. We still provide two separate Keycloak Admin clients, one with Jakarta EE and the other with Java EE support.

The User API now supports querying the number of users based on custom attributes. For that, a new q parameter was added to the /{realm}/users/count endpoint.

The q parameter expects the following format q=<name>:<value> <name>:<value> . Where <name> and <value> represent the attribute name and value, respectively.

The are additional fields available in the keycloak.status to facilitate keycloak being a scalable resource. There are also additional fields that make the status easier to interpret such as observedGeneration and condition observedGeneration and lastTransitionTime fields.

The condition status field was changed from a boolean to a string for conformance with standard Kubernetes conditions. In the CRD it will temporarily be represented as accepting any content, but it will only ever be a string. Please make sure any of your usage of this field is updated to expect the values "True", "False", or "Unknown", rather than true or false.

In scenarios where advanced management is needed you may now directly update most fields on operator managed resources that have not been set by the operator directly. This can be used as an alternative to the unsupported stanza of the Keycloak spec. Like the unsupported stanza these direct modifications are not considered supported. If your modifications prevent the operator from being able to manage the resource, there Keycloak CR will show this error condition and the operator will log it.

OpenID Connect identity providers support a new configuration to specify that the ID tokens issued by the identity provider must have a specific claim, otherwise the user can not authenticate through this broker.

The option is disabled by default; when it is enabled, you can specify the name of the JWT token claim to filter and the value to match (supports regular expression format).

The new hardcorded group mapper allows adding a specific group to users brokered from an Identity Provider.

The new user session note mapper allows mapping a claim to the user session notes.

LDAP option to use truststore SPI Only for ldaps has been removed. This parameter is used to select truststore for TLS-secured LDAP connection: either internal Keycloak truststore is picked ( Always ), or the global JVM one ( Never ).

Deployments where Only for ldaps was used will automatically behave as if Always option was selected for TLS-secured LDAP connections.

If an application client is using non http(s) custom schemes, from now on the validation requires that a valid redirect pattern explicitly allows that scheme. Example patterns for allowing custom scheme are custom:/test , custom:/test/* or custom:* . For security reasons a general pattern like * does not cover them anymore.

Having multiple repositories introduced a lot of complexity and toil. For example frequently multiple pull requests had to be sent to different repositories for a single change.

FIPS 140-2 support in Keycloak, which was preview in the previous release, is now promoted to be officially supported.

The Account Console version 3 is now available as an experimental feature in Keycloak. This version supports custom fields created with the 'User Profile' feature. If you are looking to try it out and provide us with some early feedback you can enable it as follows:

bin/kc.sh start-dev --features=account3

In Keycloak 19 the new admin console was graduated to the new default admin console, and the old admin console was deprecated. In this release the old admin console has been removed completely.

Keycloak provides an optional a metrics endpoint which exports metrics in the Prometheus format. In this release the implementation to provide this data switched from SmallRye to Micrometer. Due to this change, metrics have been renamed.

See the migration guide for details.

Running the Keycloak server with Java 11 is now deprecated, and planned to be removed in Keycloak 22.

Adapters remain supported on Java 8, Java 11, and Java 17. However, we are planning to remove support for Java 8 in the not too distant future.

We removed the out-of-box support for Hashicorp vault in this release.

The IS_CLIENT_ROLE searchable field from the RoleModel was deprecated. It should be replaced with the CLIENT_ID searchable field used with the operators EXISTS or NOT_EXISTS . See JavaDoc of Keycloak 21 for more details.

In addition to recognize the non-standard X-Forwarded-* to fetch information added by proxies that would otherwise be altered or lost when proxy servers are involved in the path of the request, Keycloak can now leverage the standard Forwarded header for the same purpose.

In Keycloak 17.0.0 the new Quarkus based distribution of Keycloak, while the WildFly based distribution was deprecated. With this release the WildFly distribution has been removed, and is no longer supported.

We are happy to announce that the new Keycloak Operator for the Quarkus based distribution is no longer a preview feature. We added new functionality as well as a number of improvements, some which has resulted in breaking changes.

Keycloak now supports OpenJDK 17 both for the server and adapters.

With the removal of the WildFly based distribution there is no longer support for running the Keycloak server on OpenJDK 8. We also plan to remove support for Keycloak adapters on OpenJDK 8 in Keycloak 21.

Starting with Keycloak 22 we plan to only support the latest OpenJDK LTS release and aiming to quickly also support the latest OpenJDK release. That means we will be also removing OpenJDK 11 support for the Keycloak server in Keycloak 22.

In this release, we are introducing two additional server options to set the base URL for frontend request and the Admin Console:

Keycloak ships for development purposes with an H2 database driver. As it is intended for development purposes only, it should never be used in a production environment.

In this release, the H2 driver has been upgraded from version 1.x to version 2.x.

Applications are able to load keycloak.js directly from the Keycloak server. As it’s not considered a best-practice to load JavaScript libraries this way there is now a feature guard that allows disabling this ability.

In Keycloak 21 we will deprecate this option, and in Keycloak 22 we plan to completely remove the ability to load keycloak.js from the Keycloak server.

In previous releases the list of OTP applications displayed to users was hard-coded in Keycloak. With the introduction of the OTP Application SPI it is now possible to disable built-in OTP applications, as well as adding custom OTP Applications.

There is now experimental support for deploying Keycloak into a FIPS 140-2 enabled environment. There will be a blog post with the details shortly after the release with the details how you can try it. Feedback is welcome!

Some Keycloak OpenID Connect adapters have reached end-of-life and are not included in this release.

JBoss AS 7 has been unmaintained for a very long time. If you are still using JBoss AS 7 we recommend migrating to WildFly and leveraging the native OIDC support in WildFly.

Jetty 9.2 reached end of life in 2018, while Jetty 9.3 reached end of life in 2020. If you are still using these versions we recommend upgrading to Jetty 9.4 as soon as possible.

Spring Boot 1.x reached end of life in 2019. If you are still using Spring Boot 1 we recommend upgrading to Spring Boot 2 as soon as possible.

In WildFly 25 the legacy security layer was removed, going forward only Elytron will be supported. We recommend anyone using an older version of WildFly to upgrade and leverage native OIDC support in WildFly.

The Keycloak storage is changing, and the current storage, while still supported, will eventually be replaced with a brand-new implementation. This change brings better support for cloud-native storages, no-downtime abilities, and better support for implementing custom storages for additional areas apart from users.

It means several deep changes in the supported features of the current store will become legacy features. The legacy store and the new store cannot be used simultaneously; only one store can be active at a time.

The most visible change is that the User Storage SPI is incompatible with the new storage API, the Map Storage API. Thus, the User Storage SPI will be deprecated with legacy store and will move to a separate module called keycloak-model-legacy . This change impacts several areas, especially areas related to user federation and custom user providers.

Furthermore, APIs have been consolidated so that the details of the storage layer will be transparent to the REST service layer. Specifically, the services will not be able to differentiate cached and non-cached objects, nor specifically access federated versus local storage.

In the previous release, we added support for OIDC logout. This release contains a few other fixes and polishing. The highlights include:

Support for the client_id parameter, which was added in recent draft of the OIDC RP-Initiated Logout specification. As a result, no need exists to use the Consent Required flag of the client to show the logout confirmation screen.

Configuration option Valid Post Logout Redirect URIs added to the OIDC client. This change is aligned with the OIDC specification, which allows you to use a different set of redirect URIs for redirect after login and logout. Value + used for Valid Post Logout Redirect URIs means that the logout will use the same set of redirect URIs as specified by the option of Valid Redirect URIs . This change also matches the default behavior when migrating from a previous version due to backwards compatibility.

Starting with version 19, Keycloak supports sending logs using GELF to centralized logging solutions like ELK, EFK or Graylog out of the box.

To avoid version conflicts with the legacy Operator, the 18.0.0 version of the new Operator is released as version 20.0.0-alpha.1 on OperatorHub. The legacy Operator versioning scheme remains the same, i.e. it is released as 18.0.0.

The same pattern will apply for future Keycloak 18 and 19 releases, until version 20 where the legacy Operator reaches EOL.

The new Admin Console is now graduated to preview, with the plan for it to become the default admin console in Keycloak 19.

Keycloak now supports Step-up authentication. This feature was added in Keycloak 17, and was further polished in this version.

Keycloak now supports Client Secret Rotation through customer policies. This feature is now available as a preview feature and allows that confidential clients can be provided with realm policies allowing the use up to two secrets simultaneously.

Recovery Codes as another way to do two-factor authentication is now available as a preview feature.

Some fixes and improvements were made to make sure that Keycloak is now fully compliant with all the OpenID Connect logout specifications:

The upload-script feature has been marked as deprecated for a very long time. In this release, it was completely removed, and it is no longer supported.

If you are using any of these capabilities:

Keycloak now supports limits on the number of sessions a user can have. Limits can be placed at the realm level or at the client level.

The Keycloak Quarkus distribution now initially supports logging to a File and logging structured data using JSON.

The Keycloak Quarkus distribution now supports expanding values in keycloak.conf from environment variables.

The default Keycloak distribution is now based on Quarkus. The new distribution is faster, leaner, and a lot easier to configure!

We appreciate migrating from the WildFly distribution is not going to be straightforward for everyone, since how you start and configure Keycloak has radically changed. With that in mind we will continue to support the WildFly distribution until June 2022.

A lot of effort went into polishing and improving the Quarkus distribution to make it as good as an experience as possible. A few highlights include:

A new approach to documentation in form of server guides to help you install and configure Keycloak

Upgraded Quarkus to 2.7.0.Final

Configuration file is no longer Java specific, and aligns configuration keys with CLI arguments

Clearer separation between build options and runtime configuration .

h2-mem and h2-file databases renamed to dev-mem and dev-file .

Simplified enabling and disabling features

Custom, and unsupported, Quarkus configuration is done through conf/quarkus.properties .

Keycloak now supports a glob-like syntax for the user search when listing users in the Admin Console, which allows for three different types of searches: prefix ( foo* which became the default search), infix ( *foo* ), and exact "foo" )

Keycloak server was upgraded to use Wildfly 26.0.0.Final as the underlying container.

Keycloak server was upgraded to use Wildfly 25.0.1.Final as the underlying container.

WildFly 25 drops support for the legacy security subsystem, which is being replaced fully by Elytron. This requires significant changes to how Keycloak is configured. Please, refer to the migration guide for more details.

Keycloak.X Quarkus preview distribution was upgraded to Quarkus 2.5.3.

Without comparison the biggest highlight of this release is all the improvements that have been made to the Quarkus distribution. So many in fact, that it will be hard to list them all.

The CLI has been polished to hell and back, and we believe it now provides a very simple and convenient approach to configuring and running Keycloak. It’s almost so simple that documentation shouldn’t be needed.

To get started, just unpack the distribution, then type bin/kc.[sh|bat] -h to discover awesomeness!

That doesn’t mean we don’t plan to provide documentation for configuring Keycloak, but it didn’t quite make it this time around. In lack of documentation expect a blog post to follow the release introducing all the changes to the Quarkus distribution, as well as an overview on how to use it.

We are rapidly moving towards making the Quarkus distribution our default distribution, and will soon deprecate the WildFly distribution. With this in mind it is important that as many people as possible give it a test-run and provide us with feedback if you find any usability issues, are not able to configure something with it, or if you discover any bugs.

The new admin console is shaping up really nicely, and a preview is included in the main distribution. It is not quite feature complete yet, but there are still loads of things to try out.

Upgrading from WildFly 23 to WildFly 25 has taken a lot longer than we would have liked. We’re still working hard on this and are hoping to release Keycloak 16 as soon as possible with the upgrade, but as we wanted to get the updates to the Quarkus distribution out there we are doing this release in the meantime.

In WildFly 25 there is now excellent native OpenID Connect support without the need for the Keycloak adapter. With this in mind we are deprecating our WildFly adapter and will not support WildFly 25, but it will be around for a while for older WildFly versions and Red Hat JBoss Enterprise Application Platform 7.y.

A long time ago, with Spring Security 5.0, there is now native support for OAuth 2.0 and OpenID Connect in Spring. With this in mind now is the time to start deprecating our Spring Boot and Security adapters.

With this release, we have deprecated and/or marked as unsupported some features in the Keycloak Operator. This concerns the Backup CRD and the operator managed Postgres Database.

In this version, there were several improvements to the User Profile SPI in order to prepare the ground on how users profiles are managed in Keycloak.

The support for configuring maximum number of active authentication sessions. The default value is set to 300 authentication sessions (browser tabs) per a browser’s session

Support for OAuth 2.0 Device Authorization Grant is now available.

Support for OpenID Connect Client Initiated Backchannel Authentication (CIBA) is now available.

Keycloak can now leverage PKCE when brokering to an external OpenID Connect IdP.

Default roles are now internally stored as composite roles of a new role usually named default-roles-<realmName> . Instead of assigning both realm and all client default roles directly to newly created users or users imported through Identity Brokering, just the role is assigned to them and the rest of default roles are assigned as effective roles. This change improves performance of default roles processing, especially with larger number of clients, because it is no longer necessary to go through all clients.

Introduction a preview of the new and upcoming Keycloak.X distribution. This distribution is powered by Quarkus, bringing significant improvements to startup time and memory consumption, as well as making it a lot easier to configure Keycloak.

The new account console is no longer a preview feature and is now the default account console in Keycloak. The old account console will stay around for a while. For those that have a custom theme for the old account console the old console will be used by default, giving you the time to update your custom theme to the new account console.

The Keycloak server was upgraded to use Wildfly 21 as the underlying container.

Support for specification of AuthnContext section in authentication requests issued by SAML identity provider has been added.

The Keycloak login theme components have been upgraded to PatternFly 4. The old PatternFly 3 runs simultaneously with the new one, so it’s possible to have PF3 components there.

Support for LDAPv3 password modify operation was added. Also the ability in the admin console to request metadata from the configured LDAP server to see if it supports LDAPv3 password modify operation.

Namespace support for LDAP group mapper allows you to map groups from LDAP under specified branch (namespace) of the Keycloak groups tree. Previously groups from LDAP were always added as the top level groups in Keycloak.

With Identity Brokering Sync Mode it is now possible to control if user profiles are updated on first login, or every login from an external Identity Provider. It is also possible to override this behaviour on individual mappers.

Typically, an SSO session last for days if not months, while individual client sessions should ideally be a lot shorter. With the introduction of client session timeout it is now possible to configure a separate timeout for individual clients, as well as a default for all clients within a realm.

For applications that use Keycloak as an OAuth 2.0 Authorization Server there is now support to revoke refresh tokens through the token revocation endpoint.

A new SPI was introduced to allow better flexibility when setting security related headers on responses. This provides a cleaner implementation within Keycloak, but also allows full customisation if needed. Security headers are now set by a response filter instead of within the code itself, which makes it less error-prone, removing the chance that some response are missing headers.

Keycloak server was upgraded to use WildFly 19 under the covers.

Support for invoking Application Initiated Actions added to Keycloak JavaScript adapter

Performance improvements to fetching resources and policies during evaluation

The promiseType init option has been removed from the JavaScript adapter. Instead a promise that supports both native promise API and legacy Keycloak promise API is returned. This allows gradually migration of applications from the legacy/deprecated API to the native promise API.

In 9.0.0 a breaking API change was introduced to LocaleSelectorSPI. With 9.0.1 the changes to this API is now reverted, and a new LocaleUpdaterSPI has been introduced.

In previous releases, Spring Boot applications had to manually implement the KeycloakConfigResolver interface or extend the built-in org.keycloak.adapters.springboot.KeycloakSpringBootConfigResolver .

This release fixes the backward compatibility issue by resolving instances automatically in case none is provided. As well as still allowing applications to provide their own configuration resolver implementations.

A new built-in vault provider that reads secrets from a keystore-backed Elytron credential store has been added as a WildFly extension. The creation and management of the credential store is handled by Elytron using either the elytron subsystem or the elytron-tool.sh script.

In this release, we did some usability improvements to the authentication flows. It should be easier for the end user to choose between available authentication mechanisms for two-factor authentication. It should be more intuitive to log in with OTP or WebAuthn considering the fact that user can have more OTP or WebAuthn credentials. There is also better support for passwordless WebAuthn authentication. Finally, we did some work on defects related to the authentication flows.

A number of improvements have been made to how the locale for the login page is selected, as well as when the locale is updated for a user.

Starting with version 80, Google Chrome will change the default value for the SameSite cookie parameter to Lax . Therefore, changes were required to several Keycloak cookies (especially those which are used within the Javascript adapter for checking the session status using the iframe) to set SameSite parameter to None . Please note that this setting also requires setting the Secure parameter, hence starting with this version, the Javascript adapter will only be fully functional when using the SSL / TLS connection on the Keycloak side.

This release fixes a critical vulnerability in LDAP introduced in Keycloak 7. If you are using Keycloak 7.0.0, 7.0.1 or 8.0.0 in production we strongly suggest that you upgrade immediately.

Upgrade to WildFly 18.0.1.Final which includes updates to a number of CVEs in third-party libraries.

Several configuration fields can obtain their value from a vault instead of entering the value directly: LDAP bind password, SMTP password, and identity provider secrets.

Furthermore, new vault SPI has been introduced to enable development of extensions to access secrets from custom vaults.

The fixed and request hostname providers have been replaced with a single new default hostname provider. This provider comes with a number of improvements, including:

We have added a new SPI that allows for the configuration of custom role mappers that are used by the SAML adapters to map the roles extracted from the SAML assertion into roles that exist in the SP application environment. This is particularly useful when the adapters need to communicate with third party IDPs and the roles set by the IDP in the assertion do not correspond to the roles that were defined for the SP application. The provider to be used can be configured in the keycloak-saml.xml file or in the keycloak-saml subsystem. An implementation that performs the role mappings based on the contents of a properties file was also provided.

Notice that when Keycloak acts as the IDP we can use the built-in role mappers to perform any necessary mappings before setting the roles into the assertion, so this SPI will probably be redundant in this case. The RoleMappingsProvider SPI was designed for situations when the IDP offer no way to map roles before adding them to the assertion.

Keycloak server was upgraded to use WildFly 18 under the covers.

With the arrival of W3C Web Authentication support, we’ve refined the authentication flow system to be able to allow a user to select which authentication method is preferred for login (for example, the choice between an OTP credential and a WebAuthn credential). The new mechanisms also allow an administrator to craft flows for password-less login, for example just using WebAuthn as an authentication method. Please note that with these changes, any custom authentication flow you have created may need to be adapted to the new flow logic.

Until now, administrators were allowed to upload scripts to the server through the Keycloak Administration Console as well as through the RESTful Admin API.

A lot of work has been done on the new Account Console and Account REST API. It’s not quite ready yet, but it’s getting there and hopefully will be fully done for Keycloak 8.

The Keycloak team has spent a significant amount of time on automation around testing and releases both for Keycloak and Red Hat Single Sign-On.

Keycloak now comes enabled with the SmallRye Health and Metrics extensions which provides standard health and metrics endpoints. We will add some documentation as well as Keycloak specific metrics soon.

It is now possible to fully secure OpenShift 3.11 with Keycloak, including the ability to automatically expose Service Accounts as OAuth clients as clients to Keycloak.

This is currently a technology preview feature.

DB2 support has been deprecated for a while. With this release we have removed all support for DB2.

Introduced the ability to specify different session idle and max timeouts for remember me sessions. This enables remember me sessions to live longer than regular sessions.

Large numbers of groups have previously caused issues in the admin console. This is now resolved by the introduction of pagination of groups.

In the past, starting the server could take a long time if there were many offline sessions. This startup time has now been significantly reduced.

Keycloak Gatekeeper provides a security proxy that can be used to secure applications and services without an adapter. It can be installed locally alongside your application or as a sidecar on OpenShift or Kubernetes.

The Signature SPI makes it possible to plug-in additional signature algorithms. This enables additional signatures and also enables changing how signatures are generated. For example, using this allows using an HSM device to sign tokens.

Alongside the Signature SPI there is now also support for additional signature algorithms.

Keycloak now has support for RS256, RS384, RS512, ES256, ES384, ES512, HS256, HS384 and HS512.

Elliptic Curve Digital Signature Algorithm (ES256/384/512) are very interesting as they provide similar security properties as RSA signatures, but use significantly less CPU.

HMAC (HS256/384/512) are also very useful when you do not want your application to verify the signature itself. Since these are symmetric signatures only Keycloak is able to verify the signature, which requires the application to use the token introspection endpoint to verify tokens.

It is now possible to specify the audiences in the tokens issued for OpenID Connect clients. There is also support for verification of audience on the adapter side.

Having authorization services support in Node.js makes it very easy to do fine-grained central authorization with the Node.js adapter.

Update design for the welcome page

The hostname SPI introduces a more flexible way to configure the hostname for Keycloak. There are two built-in providers. The first is request, which uses the request headers to determine the hostname. The second is fixed, which allows configuring a fixed hostname. The latter makes sure that only valid hostnames can be used and also allows internal applications to invoke Keycloak through an alternative URL.

The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition to that the Keycloak Server validates Subject DN field of the client’s certificate.

For this release, we improved policy evaluation performance across the board, increasing reliability and throughput. The main changes we did were related with trying to optimize the policy evaluation path by avoiding unnecessary flows and collect decisions as soon as they happen. We also introduced a policy decision cache on a per-request basis, avoiding redundant decisions from policies previously evaluated.

In previous versions, permissions were always returned from the server using standard OAuth2 response, containing the access and refresh tokens. In this release, clients can use a response_mode parameter to specify how the server should respond to an authorization request. This parameter accepts two values: