Last checked and updated on April 19, 2026What Is New in Keycloak 26.0
Keycloak 26.0 delivers a significant update focused on modernizing the admin console, enhancing security protocols, and improving the developer experience. This release introduces a new React-based admin UI, stricter OAuth 2.0 compliance, and crucial groundwork for future authentication flows.
| Category | Key Changes |
|---|---|
| New Features | New Admin UI (v2), OAuth 2.0 Token Exchange, CIBA grant type preview, Dynamic Client Scopes |
| Improvements | Stricter OAuth 2.0 compliance, Enhanced client policies, Better JavaScript policy support |
| Deprecations | Original Admin UI (v1), Legacy store, Default value for `kc_idp_hint` |
| Security | Removed BouncyCastle dependency, Updates to JWS and JWE algorithms |
Why is the new Admin UI a big deal?
The new Admin UI v2 is a complete rewrite from PatternFly 4 to PatternFly 5 and React. This isn't just a visual refresh; it's a foundational shift for maintainability and future feature development. The old UI (v1) is now deprecated and will be removed in a future release.
In practice, the new interface is more responsive and sets the stage for a better user experience. You can switch back to the legacy UI for now using a toggle, but it's time to start getting familiar with the new React-based console.
What OAuth 2.0 compliance changes should I watch for?
Keycloak 26.0 enforces stricter compliance with the OAuth 2.0 specification, which might break existing non-compliant clients. The main change involves the handling of the client_id parameter in token requests.
For public clients, the client_id is now mandatory in token endpoint requests. Previously, it could be omitted if the client was authenticated another way, like with basic auth. This matters because it ensures consistency and prevents ambiguous authentication scenarios. Check your client implementations to avoid unexpected authentication failures.
How does the Token Exchange improvement work?
Token Exchange is now a fully supported feature, moving out of its preview state. It allows a client to exchange an existing token for a new one targeting a different client or user, which is essential for microservices architectures and delegation scenarios.
This formalization means the feature is stable and ready for production use. You can now more confidently implement patterns where a service needs to act on behalf of a user to call another service without the user's credentials.
What's new for client policies and scopes?
Client policies have been enhanced with new conditions and executors, giving admins finer-grained control over client registration and authentication. A significant addition is support for Dynamic Client Scopes.
Dynamic Client Scopes allow you to define scopes that are created on-the-fly based on protocol mappers, rather than being statically pre-configured. This is powerful for creating more flexible and customized authentication experiences without cluttering the scope list with every possible permutation.
Is the CIBA grant type ready to use?
The Client Initiated Backchannel Authentication (CIBA) grant type is available as a preview feature. CIBA is designed for decoupled authentication flows, where the user authenticates on a separate device from the one initiating the request (e.g., using a mobile app to approve a login on a smart TV).
Since it's in preview, it's not recommended for critical production workloads yet. However, this is the first step toward supporting a modern, standard flow for IoT and cross-device authentication use cases.
FAQ
Is the old Admin UI being removed immediately?
No, the original Admin UI (v1) is deprecated but still available. You can switch to it using a toggle in the new UI. However, it will be removed in a future major release, so migration to the new React-based UI is advised.
Will the OAuth 2.0 compliance changes break my clients?
It might break non-compliant clients, specifically public clients that omitted the `client_id` parameter in token endpoint requests. Review your client code to ensure it sends the `client_id` as required by the spec.
What is the impact of removing the BouncyCastle dependency?
This change simplifies the security provider setup and reduces dependencies. Keycloak now relies on the Java runtime's built-in cryptographic providers, which is a more streamlined and maintainable approach.
Can I use Dynamic Client Scopes with existing clients?
Yes, Dynamic Client Scopes work with both new and existing clients. They are evaluated dynamically when a token is requested, providing flexibility without requiring changes to pre-configured client scope mappings.
How do I enable the preview CIBA grant type?
Preview features are not enabled by default. You must start the server with the `--features=preview` or `--features=ciba` flag to experiment with the Client Initiated Backchannel Authentication flow.