Latest in branch 24.0
24.0.10
Released 12 Feb 2025
(1 year ago)
SoftwareKeycloak
Version24.0
Status
End of life
Supported
Java versions
Java 17
Initial release24.0.0
04 Mar 2024
(2 years ago)
Latest release24.0.10
12 Feb 2025
(1 year ago)
End of life10 Jun 2024
(Ended 1 year, 11 months ago)
Release noteshttps://github.com/keycloak/keycloak/releases/tag/24.0.10
Source codehttps://github.com/keycloak/keycloak/tree/24.0.10
Documentationhttps://github.com/keycloak/keycloak/tree/24.0.10/docs
Keycloak 24.0 ReleasesView full list

What Is New in Keycloak 24.0

Keycloak 24.0 introduces significant updates focused on modernizing the codebase and enhancing security. The major theme is the removal of legacy features and a push towards a more streamlined, maintainable platform.

Category Key Changes
New Features New admin console, support for OpenID Connect Identity Assurance, early access for Declarative User Profiles.
Deprecations & Removals Legacy WildFly distribution, JavaScript adapter, and SAML protocol removals.
Security Deprecation of DPoP proof JWT re-use, removal of the 'offline_session' claim.
Improvements Quarkus 3.8 upgrade, new account console, enhanced client policies.

Why is the legacy WildFly distribution gone?

The legacy WildFly distribution has been completely removed in favor of the Quarkus-based distribution. This was a planned obsolescence, as the Quarkus distribution has been the default and recommended option for several releases.

In practice, this means all new deployments and migrations must use the Quarkus distribution. This shift simplifies the architecture and aligns with modern, cloud-native deployment patterns.

What happened to the JavaScript adapter?

The deprecated JavaScript adapter has been removed from Keycloak 24.0. It was officially deprecated in a previous release and has now been taken out of the codebase entirely.

You should now use the official JavaScript client from the Keycloak GitHub organization. This new library is actively maintained and follows modern JavaScript standards.

How has the SAML protocol changed?

Support for the SAML protocol has been removed from the new admin and account consoles. The SAML protocol itself is still supported on the server-side for existing installations.

This change reflects the industry's stronger focus on OpenID Connect. For new projects, OIDC is the recommended protocol. The server-side SAML support is now considered a legacy feature.

What's new for client policies?

Client policies have been enhanced with a new condition and executor. A new client-scope condition allows for more granular policy control based on the client scopes that are assigned.

There's also a new executor that can be configured to refuse consent for a client, providing another layer of security policy enforcement. These changes make client policies more powerful and flexible.

FAQ

I rely on the JavaScript adapter. What should I do now?
You must migrate to the new Keycloak JavaScript adapter available at the Keycloak GitHub organization. The old adapter will no longer receive updates or security patches, so migrating is critical for security.

Is my existing SAML setup broken with this release?
No, server-side SAML support remains intact for now. Only the SAML management functionality within the new admin and account consoles has been removed. Your existing SAML identity providers and service providers should continue to work.

What is the immediate impact of the 'offline_session' claim removal?
If you have custom scripts or external systems that parsed the ID token and relied on this claim, they will break. You need to update your logic to handle its absence. The claim was non-standard and its removal simplifies the token structure.

How do I get started with Declarative User Profiles?
This is an early access feature. You need to enable it by starting the server with the `-Dkeycloak.profile.feature.declarative_user_profile=enabled` flag. This allows you to define user profile configurations in the realm settings instead of using custom code.

Why was DPoP proof JWT re-use deprecated?
Allowing a DPoP proof JWT to be used more than once was a potential security risk. The specification recommends that proofs are used only once. This change enforces a stricter security posture for DPoP-bound access tokens.

Releases In Branch 24.0

VersionRelease date
24.0.1012 Feb 2025
(1 year ago)
24.0.927 Nov 2024
(1 year ago)
24.0.819 Sep 2024
(1 year ago)
24.0.710 Sep 2024
(1 year ago)
24.0.615 Jul 2024
(1 year ago)
24.0.504 Jun 2024
(2 years ago)
24.0.408 May 2024
(2 years ago)
24.0.316 Apr 2024
(2 years ago)
24.0.224 Mar 2024
(2 years ago)
24.0.105 Mar 2024
(2 years ago)
24.0.004 Mar 2024
(2 years ago)