<div>
<h2>Highlights</h2>
<div class="paragraph">
<p>This release features new capabilities for users and administrators of Keycloak. The highlights of this release are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Automate user provisioning with the SCIM API (preview)</p>
</li>
<li>
<p>Simplified multi-cluster high availability without external caches (preview)</p>
</li>
<li>
<p>Enhanced reverse proxy guides with blueprints for HAProxy and Traefik</p>
</li>
<li>
<p>Step-up authentication for SAML clients</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Read on to learn more about each new feature.
If you are upgrading from a previous release, <a href="https://www.keycloak.org/docs/latest/upgrading/index.html">also review the changes listed in the upgrading guide</a>.</p>
</div>
<div class="sect2">
<h3 id="_security_and_standards">Security and Standards</h3>
<div class="sect3">
<h4 id="_stronger_security_for_the_identity_brokering_api">Stronger security for the Identity Brokering API</h4>
<div class="paragraph">
<p>The Identity Brokering API allows applications to retrieve tokens obtained from external identity providers during federated login. Version 2 of this API replaces the legacy V1 with a more secure and standards-compliant design:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>Client-level authorization</strong> — access to external tokens is controlled per client using dedicated settings (<strong>Allow retrieve external tokens</strong> and an identity provider allow list) instead of assigning broker roles to individual users.</p>
</li>
<li>
<p><strong>Confidential clients only</strong> — public clients are rejected, ensuring that only authenticated clients can retrieve external tokens.</p>
</li>
<li>
<p><strong>OAuth 2.0 compliant</strong> — the endpoint uses <code>POST</code> and returns standard JSON responses with <code>access_token</code>, <code>error</code>, and <code>error_description</code> fields.</p>
</li>
<li>
<p><strong>Session-based token storage</strong> — a new <strong>Store token in session</strong> option keeps tokens in the user session for faster access, with automatic cleanup on session expiry. Database storage remains available for persistence across sessions.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>V2 is now supported but disabled by default. V1 is deprecated but still enabled by default for backward compatibility. In a future release, V1 will be removed and V2 will become the default.</p>
</div>
<div class="paragraph">
<p>For more information, see the <a href="https://www.keycloak.org/docs/26.7.0/server_development/#_identity-brokering-apis">Identity Brokering APIs</a> chapter in the Server Developer Guide.</p>
</div>
</div>
<div class="sect3">
<h4 id="_progress_on_verifiable_credentials_oid4vci_experimental">Progress on Verifiable Credentials (OID4VCI) (experimental)</h4>
<div class="paragraph">
<p><a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html">Verifiable Credentials (OID4VCI)</a> allow organizations to issue tamper-proof, cryptographically signed credentials — such as employee badges, academic diplomas, or professional certifications — that users can store in a digital wallet and present to third parties without involving the issuer.</p>
</div>
<div class="paragraph">
<p>OID4VCI remains an experimental feature in Keycloak, but this release brings substantial improvements from both the core team and the community:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Polishing of existing functionality and improving configuration. Everything is now configurable in the admin UI in addition to the admin REST API.</p>
</li>
<li>
<p>Lots of bugs fixed. Improved specification compliance.</p>
</li>
<li>
<p>Conformance with the <a href="https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html">OpenID4VC High Assurance Interoperability Profile (HAIP)</a>.
This work involves the introduction of the dedicated Keycloak experimental feature <code>client-auth-abca</code> for <a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-07">Attestation based client authentication (ABCA)</a>.</p>
</li>
<li>
<p>Management of verifiable credentials for individual users. This involves the ability for an administrator to create a verifiable credential for a user
to indicate that this user can retrieve a verifiable credential, as well as the ability for users to start issuance of a verifiable credential from the Keycloak account console.</p>
</li>
<li>
<p><a href="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-pre-authorized-code-flow">Pre-authorized code grant</a> support is still experimental and was moved to the dedicated experimental feature <code>oid4vc-vci-preauth-code</code></p>
</li>
<li>
<p>Support for credential refresh interval. Administrators can now configure a separate refresh interval (<code>vc.refresh_interval_in_seconds</code>) in the client scope settings that controls how often wallets must refresh the credential, independent of the credential lifetime. When not explicitly set, defaults to 7 days or the credential lifetime, whichever is smaller. This enables regular credential rotation for enhanced security while maintaining user convenience through automatic refresh using the refresh token. For more information, see the <a href="https://www.keycloak.org/docs/26.7.0/server_admin/#_oid4vci_client_scope">Create Client Scopes with Mappers</a> section in the OID4VCI configuration guide.</p>
</li>
<li>
<p>Documentation updated and improved</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Many community members were involved in the development. Many thanks to <a href="https://github.com/Awambeng">Awambeng</a>,
<a href="https://github.com/Captain-P-Goldfish">Pascal Knüppel</a>, <a href="https://github.com/dominikschlosser">Dominik Schlosser</a>, <a href="https://github.com/forkimenjeckayang">forkimenjeckayang</a>,
<a href="https://github.com/IngridPuppet">Ingrid Kamga</a>, <a href="https://github.com/keshavprashantdeshpande">Keshav Deshpande</a>, <a href="https://github.com/namanONcode">Naman Jain</a>,
<a href="https://github.com/officialasishkumar">Asish Kumar</a>, <a href="https://github.com/Ogenbertrand">Ogen Bertrand</a>, <a href="https://github.com/Oluwatobi-Mustapha">Oluwatobi Mustapha</a>,
<a href="https://github.com/pulsastrix">Hugo Hakim Damer</a>, <a href="https://github.com/rameshkumarkoyya">rameshkumarkoyya</a>, <a href="https://github.com/tdiesler">Thomas Diesler</a> and
<a href="https://github.com/Vitalisn4">Palpable</a> for the contributions!</p>
</div>
</div>
<div class="sect3">
<h4 id="_cross_domain_token_exchange_with_identity_assertion_jwt_grant_experimental">Cross-domain token exchange with Identity Assertion JWT Grant (experimental)</h4>
<div class="paragraph">
<p>When two organizations each run their own authorization server, users often need to re-authenticate when crossing between them — even though their identity was already verified. The <a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant">Identity Assertion JWT Authorization Grant (ID-JAG)</a> solves this by allowing one authorization server to present a signed identity assertion to another, which then issues an access token without requiring the user to log in again.</p>
</div>
<div class="paragraph">
<p>Keycloak provides partial experimental support for the Identity Assertion JWT Authorization Grant. It currently implements only the receiving authorization server role, accepting ID-JAG assertions at the token endpoint and issuing access tokens in return. Other parts of the ID-JAG specification are not yet implemented, so the complete flow is not currently supported.</p>
</div>
<div class="paragraph">
<p>To try it out, start Keycloak with the feature <code>identity-assertion-jwt</code> enabled.</p>
</div>
<div class="paragraph">
<p>Many thanks to <a href="https://github.com/bucchi">Yutaka Obuchi</a> for the contribution of this feature!</p>
</div>
</div>
<div class="sect3">
<h4 id="_automate_user_provisioning_with_the_scim_api_preview">Automate user provisioning with the SCIM API (preview)</h4>
<div class="paragraph">
<p><a href="https://datatracker.ietf.org/doc/html/rfc7644">SCIM</a> (System for Cross-domain Identity Management) is a standard protocol for reading and writing identity resources such as users and groups across multiple systems. It enables organizations to automate user provisioning and deprovisioning using widely available tooling — for example, integrating with identity governance platforms, HR systems, or other identity providers.</p>
</div>
<div class="paragraph">
<p>Keycloak has SCIM APIs for managing users and groups within a realm. The implementation covers full CRUD and PATCH operations, filtering and pagination, schema extensions including the Enterprise User extension, and schema discovery endpoints.</p>
</div>
<div class="paragraph">
<p>In this release, the SCIM API is being promoted to a preview feature. In the default profile it is disabled by default; to try it out, enable the <code>scim-api</code> feature.</p>
</div>
<div class="paragraph">
<p>For more details, see the <a href="https://www.keycloak.org/docs/26.7.0/server_admin/#_managing_scim">Managing users and groups through SCIM</a> documentation.</p>
</div>
</div>
<div class="sect3">
<h4 id="_real_time_security_signals_to_downstream_applications_experimental">Real-time security signals to downstream applications (experimental)</h4>
<div class="paragraph">
<p>When a user logs out, changes credentials, or gets disabled in Keycloak, downstream applications typically don’t learn about it until the next token refresh — leaving a window where stale sessions remain active. The <a href="https://openid.net/specs/openid-s
…(truncated)