Repository navigation
Replies: 6 comments 2 replies
|
Completely agree. As the leading open-source reference for identity and access management, Keycloak should align with the new standard. In fact, I was surprised to see that as of January, this wasn’t even on the roadmap. |
|
How does this work for the generated JWT? does it contain a list of Policies defined or how should keycloak enforce the policy? |
|
Keycloak will serve as the AuthZEN Policy Decision Point (PDP). |
|
Are there plans for keycloak to be able to rely on an existing PDP to enrich the claims? Something similar to the coarse-grained approach shown here: https://authzen-interop.net/docs/intro/ There are cases where keycloak acts as an IdP for downstream services that only think in terms of jwt claims to enforce authorization, hence the need for it to act as a bridge between an existing PDP and the downstream service by enriching the jwt (similar to what Auth0 proposes here) The current way is to use an 3rd party plugin like external claim mapper to call an arbitrary endpoint, but with the AuthZen protocol being a standard, perhaps this could be builtin instead. |
|
I have looked into the interop scenario and I believe it would be a good fit for Keycloak. There's no plans to implement the required functionality in the short-term, as we would first like to receive feedback on the initial AuthZEN support, but is something we are aware of and discussing. If the community is interested in Keycloak providing support for the interop scenario, it would be great for people to express that on this thread with a simple 👍 or by providing comments explaining their use-cases and how AuthZEN interop would help. |
|
The initial work to add AuthZEN as an experimental feature is now complete #48285 🎉 See the announcement blog and nightly docs for usage instructions. Please try out the feature and let us know what you think on this discussion as your feedback will help shape its future. We have also created a parent issue to track all work required in order to graduate this to a Tech Preview feature: #49016 |
|
Thanks for the experimental AuthZEN support. While testing it with authzen-enforcer, a Java PEP SDK I'm working on, I found that requests with One design question there: should |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Support for OpenID AuthZEN
Author: @embesozzi
Status: Draft
Type: Feature Proposal
Created: 2026-02-04
Abstract
This proposal introduces OpenID AuthZEN as a fine-grained authorization (FGA) mechanism within the context of authorization capabilities in the Keycloak platform.
AuthZEN is a specification developed by the OpenID Foundation AuthZEN Working Group and has been approved as an AuthZEN Authorization API 1.0 specification. It standardizes communication between Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs). This integration enables MCP deployments to externalize authorization decisions to standards-compliant PDPs, supporting multiple authorization models including relationship-based access control (ReBAC), policy-based access control (PBAC), and attribute-based access control (ABAC).
Motivation
Keycloak supports the UMA (User-Managed Access) standard, but it is not widely adopted. With the addition of AuthZEN, we can evolve and modernize Keycloak’s authorization capabilities, transforming Keycloak into an AuthZEN-compliant PDP for APIs, agents, and MCP/MCP applications.
OpenID AuthZEN as a Solution
AuthZEN addresses limitations of Scope-Based Authorization and UMA adoption by providing:
Specification Overview
AuthZEN enables to externalize fine-grained authorization decisions to a Policy Decision Point (PDP). The core concept is straightforward: the API, MCP Server or Gateway acts as a Policy Enforcement Point (PEP) that queries an external AuthZEN-compliant PDP, in this case Keycloak, before allowing operations to proceed.
flowchart LR subgraph MCP["API / MCP / Gateway Layer"] Server["API / MCP <br/>(AuthZEN PEP)"] end subgraph AuthZEN["Authorization Layer"] PDP["AuthZEN PDP<br/>(Keycloak)"] end Server -->|"Evaluation Request"| PDP PDP -->|"Decision Response"| ServerThe PEP sends an Evaluation Request containing information about the subject, resource, and action. The PDP evaluates this request against its policies and returns a Decision Response indicating whether the operation should be allowed or denied.
This pattern decouples authorization logic from application code, enabling:
AuthZEN as a Complementary Layer
AuthZEN doesn't replace OAuth - it complements it. OAuth handles coarse-grained authorization (CGA) through scopes and token validation. AuthZEN handles fine-grained authorization (FGA) through dynamic policy evaluation.
The flow for MCP:
sequenceDiagram participant Client as MCP Client participant Server as MCP Server / Gateway<br/>(PEP) participant PDP as AuthZEN PDP Client->>Server: POST /mcp (tools/call)<br/>Authorization: Bearer <token> Server->>Server: Validate OAuth Token alt Token Invalid Server-->>Client: HTTP 401 Unauthorized end Server->>Server: Extract subject from JWT claims Server->>Server: Extract resource/action from MCP request Server->>Server: Build AuthZEN Evaluation Request Server->>PDP: POST /access/v1/evaluation PDP->>PDP: Evaluate policies PDP-->>Server: {"decision": true|false} alt decision: true Server->>Server: Execute MCP method Server-->>Client: JSON-RPC Response else decision: false Server-->>Client: HTTP 403 Forbidden endAuthZEN Evaluation Request
The AuthZEN specification defines an evaluation request containing four primary components:
subjectresourceactioncontextAuthZEN Request Structure
{ "subject": { "type": "<subject_type>", "id": "<subject_identifier>", "properties": {} }, "resource": { "type": "<resource_type>", "id": "<resource_identifier>", "properties": {} }, "action": { "name": "<action_name>", "properties": {} }, "context": {} }AuthZEN Evaluation Response
The PDP returns a decision:
{ "decision": true }Or:
{ "decision": false }Benefits
Conclusion
Authorization is heading in a clear direction: standardized, decoupled, and interoperable. The OpenID Foundation’s AuthZEN specification provides a strong foundation for this transformation, and AI applications, with their dynamic, context-rich interactions, are accelerating the need for adoption.
Since Keycloak plays a critical role in core OAuth 2.0/2.1 standards within the MCP context, extending it to support fine-grained authorization (FGA) would be a natural and valuable addition.
Having in mind that we already have UMA endpoints, we could extend them to support the
/access/v1/evaluationendpoint and the AuthZEN request/response evaluation schema.We can also evaluate extending the AuthZEN integration once the IdP implements the Search API as well. I believe Thomas was working on that during the OIDF AuthZEN interoperability workshop.
References
[1] OpenID Foundation AuthZEN Working Group
[2] AuthZEN Authorization API 1.0
[3] Mastering Secure APIs and AI Agents with Zero Trust and Fine-Grained Authorization Based on OpenID AuthZEN
All reactions