Repository navigation
AuthZen API support for Authorization Services #45288
Description
Description
The OpenID Foundation started the AuthZEN [1] working group to provide standard mechanisms, protocols and formats to communicate authorization related information between components within one organization or across organizations, which may have been developed or sourced from different entities.
The working group is working on a specification to define an Authorization API [2]. This API enables Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) to communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings. The Authorization API is served by the PDP and is called by the PEP. The Authorization API includes an Evaluation endpoint, which provides specific access decisions. Other endpoints may be added in the future for other scenarios, including searching for subjects or resources.
Keycloak Authorization Services is a feature that enables a PDP [3] for individual resource servers (confidential clients) to evaluate authorization policies that govern access to their protected resources. This feature is already supported, and the underlying protocol is based on the User-Managed Access (UMA) specification. While at that time, UMA was the best/single standard describing an authorization protocol within the OAuth2 ecosystem, the work being done by the AuthZEN working group should provide a much better and simpler protocol.
After an initial study, the Authorization API specification seems to be very aligned with Keycloak's PDP, and we should be able to expose it based on it and eventually remove the dependency and support of UMA. By relying on a standard from the OpenID Foundation, we should increase the interoperability, adoption, and long-term support of our authorization capabilities.
Value Proposition
The AuthZEN Authorization API is backed by the OpenID Foundation and should provide a simpler and more interoperable protocol to expose Keycloak's PDP. It has also been adopted by different vendors in the IAM space, and should put Keycloak in pace with these vendors while improving its authorization capabilities and helping our customers to better address their authorization requirements.
Given that the Keycloak's PDP provides most of the capabilities and semantics defined in the specification, we should be able to easily adopt yet another specification from the OpenID Foundation.
Goals
- Expose the Keycloak Authorization Services PDP using the Authorization API
- Ability to evaluate authorization policies using the Authorization API
- Leverage the authorization model provided by Keycloak Authorization Services to manage resources, actions, and policies
- Examples and quickstart on how to evaluate authorization policies using the Authorization API
- Update the Keycloak Authorization Services to advertise support for the Authorization API
- The Authorization API should be an experimental feature
- Evaluate if we can consider deprecating/removing UMA support in future releases
Non-Goals
- Any form of implementation of PEP is out of scope
- Have the Authorization API fully supported. That should only be possible once the standard is no longer a draft.
- Drop UMA support
Discussion
No response
Notes
No response
Activity
[-][RHBK-2858] AuthZen API support[/-][+]AuthZen API support[/+][-]AuthZen API support[/-][+]AuthZen API support for Authorization Services[/+]y-tabata commentedon Mar 22, 2026
This is very interesting. I’m considering opening a draft PR for an Access Evaluation API in the near future, if this aligns with the current direction.
shazada commentedon Mar 24, 2026
Very interesting, following
ryanemerson commentedon Mar 31, 2026
I have created #47629 to track the minimal work required to be spec compliant by implementing the Evaluation API. I'll issue a PR shortly.
I suggest we tackle the following work in sub-issues which I will create later if people are in agreement:
X-Request-IDheaders from request to responseryanemerson commentedon Apr 20, 2026
This issues sub-issues have been restructured in order to capture the work required for an experimental MVP: #48285
Feedback welcome 🙂