OpenID AuthZEN Integration for Fine-Grained Authorization Author: @embesozzi Status: Draft Type: Feature Proposal Created: 2026-02-02 Abstract This proposal introduces OpenID AuthZEN as an optional fine-grained authorization (FGA) mechanism for the Model Context Protocol (MCP). AuthZEN is a specification developed by the OpenID Foundation AuthZEN Working Group and has been approved as an official version 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). The proposal is fully backward compatible with existing MCP authorization mechanisms and operates as a complementary layer to OAuth 2.1 token validation. Motivation Current MCP authorization relies on OAuth 2.1 with scope-based access control. While effective for coarse-grained authorization (CGA), this approach presents limitations for enterprise deployments requiring fine-grained authorization: Limitations of Scope-Based Authorization 1. Coarse Granularity: OAuth scopes operate at broad permission levels (e.g., , ) rather than resource-specific or operation-specific access decisions. 2. Static Authorization: Scopes are determined at token issuance time and cannot adapt to runtime context such as resource attributes, environmental factors, or dynamic policy changes. 3. Limited Policy Expression: Complex authorization requirements, such as "analysts may approve expenses up to $10,000 in their assigned department", cannot be expressed through OAuth scopes alone. 4. Centralized Policy Management: Without externalized authorization, policy logic becomes embedded in application code across multiple MCP Servers, creating maintenance complexity and inconsistent enforcement. OpenID AuthZEN as a Solution AuthZEN addresses these limitations by providing: A standardized interface for authorization decisions Support for multiple authorization models (ReBAC, PBAC, ABAC) Externalized policy management enabling centralized governance Runtime context evaluation for dynamic authorization decisions Specification Overview Integration Point AuthZEN enables MCP deployments to externalize fine-grained authorization decisions to a Policy Decision Point (PDP). The core concept is straightforward: the MCP Server or MCP Gateway acts as a Policy Enforcement Point (PEP) that queries an external AuthZEN-compliant PDP before allowing operations to proceed. The 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: Centralized policy management across multiple MCP Servers Dynamic policy updates without code changes Consistent enforcement of complex authorization rules Support for multiple authorization models (ReBAC, PBAC, ABAC) Authorization Flow This section describes the standard AuthZEN authorization architecture followed by an MCP-specific implementation example. AuthZEN Authorization Architecture The AuthZEN specification defines a protocol-agnostic pattern for authorization decisions. The following sequence diagram illustrates the standard flow where an MCP Server or MCP Gateway acts as the Policy Enforcement Point (PEP): The key steps in this architecture are: 1. Request Reception: The gateway receives an incoming request from the application 2. Authentication: The gateway authenticates the request using the configured mechanism 3. Context Extraction: Subject, resource, and action details are extracted from the request context 4. AuthZEN Evaluation: The PEP sends an evaluation request to the AuthZEN PDP 5. Policy Evaluation: The PDP evaluates the request against configured policies 6. Decision Enforcement: The PEP enforces the decision-forwarding the request on allow, or returning 403 Forbidden on deny MCP Implementation Example Note: The flow described below is non-normative and represents a proposed integration approach for MCP deployments that use OAuth 2.1 for authentication. See MCP-Specific Mapping Example for additional considerations on subject sources and PDP capabilities. In MCP deployments using OAuth 2.1, AuthZEN operates after OAuth token validation, functioning as a complementary authorization layer. The following sequence diagram illustrates the complete authorization flow for an MCP request: The key steps are: 1. Token Validation: The MCP Server validates the OAuth token (existing behavior) 2. Context Extraction: Subject information is extracted from JWT claims; resource and action from the MCP request 3. AuthZEN Query: The PEP sends an evaluation request to the PDP 4. Policy Evaluation: The PDP evaluates the request against configured policies 5. Decision Enforcement: The PEP enforces the decision (proceed or deny) AuthZEN Evaluation Request The AuthZEN specification defines an evaluation request containing four primary components: Request Structure MCP-Specific Mapping Example Important: The mapping described below is non-normative and provided as an illustrative example. The OpenID Foundation AuthZEN Working Group intends to define an AuthZEN Profile for MCP to standardize this mapping as an extension of the AuthZEN specification. Other considerations: Subject sources are flexible: In this example, subject information is derived from OAuth Access Token (JWT claims). This is not required-subject information can be obtained from other sources depending on the deployment architecture. PDP data sources: The AuthZEN PDP is not limited to the data provided in the evaluation request. The PDP can retrieve and incorporate external data sources (e.g., user directories, relationship graphs, resource metadata) when making policy decisions. For MCP requests, the evaluation request could be constructed as follows: Subject (derived from JWT claims): : or : Value from or claim : Additional claims such as , , (authentication context class reference), (authentication methods references) Resource: : or application-specific type : MCP namespace or resource scope (e.g., ) Action (derived from MCP request): : Tool name from : Tool arguments from Example: MCP Tool Invocation Given the following MCP request: And a JWT containing: The AuthZEN evaluation request would be: AuthZEN Evaluation Response The PDP returns a decision: Or: When is , the MCP Server proceeds with request execution. When is , the MCP Server MUST return HTTP 403 Forbidden. Benefits Relationship to MCP Authorization Extensions This proposal aligns with the MCP ext-auth extension framework principles, and I can open a ticket there to provide implementation guidance and reference configurations. Open Questions 1. Community Interest: Is the MCP community open to evaluating the addition of AuthZEN as a standardized mechanism for fine-grained authorization in MCP deployments? 2. Formalization in ext-auth: Should this proposal be formalized as an official MCP authorization extension in the repository? References AuthZEN Authorization API 1.0 OpenID Foundation AuthZEN Working Group This is the first iteration of this proposal, covering only the authorization API. If there is interest, I can clarify any questions and provide implementation examples demonstrating AuthZEN integration with MCP and MCP apps to the community.