OpenID AuthZEN Integration for Fine-Grained Authorization

[embesozzi]

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., read, write) 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.

flowchart LR
    subgraph MCP["MCP Layer"]
        Server["MCP Server / MCP Gateway<br/>(AuthZEN PEP)"]
    end

    subgraph AuthZEN["Authorization Layer"]
        PDP["AuthZEN PDP"]
    end

    Server -->|"Evaluation Request"| PDP
    PDP -->|"Decision Response"| Server

Loading

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):

sequenceDiagram
    participant App as  MCP Host
    participant Gateway as MCP Server / MCP Gateway<br/>(AuthZEN PEP)
    participant PDP as AuthZEN PDP
    participant Backend as API

    App->>Gateway: Sends request
    Gateway->>Gateway: Authenticate Request
    Gateway->>Gateway: Extract details<br/>(subject, method, resource)
    Gateway->>PDP: Sends AuthZEN request
    PDP->>PDP: Evaluates policy
    PDP-->>Gateway: Returns allow/deny decision

    alt Allow
        Gateway->>Backend: Forwards request
        Backend-->>Gateway: Returns response
        Gateway-->>App: Returns response
    else Deny
        Gateway-->>App: Returns 403 Forbidden
    end

Loading

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 tools/call request:

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
    end

Loading

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:

Component	Description
subject	The entity requesting access (user, service, agent)
resource	The target of the access request
action	The operation being performed
context	Additional contextual information

Request Structure

{
  "subject": {
    "type": "<subject_type>",
    "id": "<subject_identifier>",
    "properties": {}
  },
  "resource": {
    "type": "<resource_type>",
    "id": "<resource_identifier>",
    "properties": {}
  },
  "action": {
    "name": "<action_name>",
    "properties": {}
  },
  "context": {}
}

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 tools/call requests, the evaluation request could be constructed as follows:

Subject (derived from JWT claims):

• type: "user" or "identity"
• id: Value from sub or preferred_username claim
• properties: Additional claims such as roles, tenant, acr (authentication context class reference), amr (authentication methods references)

Resource:

• type: "mcp-tool" or application-specific type
• id: MCP namespace or resource scope (e.g., "mcp:expenses")

Action (derived from MCP request):

• name: Tool name from params.name
• properties: Tool arguments from params.arguments

Example: MCP Tool Invocation

Given the following MCP request:

{
  "jsonrpc": "2.0",
  "id": "request_12345",
  "method": "tools/call",
  "params": {
    "name": "fintech_approve_expense",
    "arguments": {
      "expense_id": "exp-123",
      "amount": 5000
    }
  }
}

And a JWT containing:

{
  "sub": "xxxxx",
  "preferred_username": "embesozzi",
  "realm_access": {
    "roles": ["analyst"]
  },
  "organization": "finance-dept",
  "acr": "inherence",
  "amr": ["passkeys"]
}

The AuthZEN evaluation request would be:

{
  "subject": {
    "type": "user",
    "id": "embesozzi",
    "properties": {
      "roles": ["analyst"],
      "tenant": "finance-dept",
      "acr": "inherence",
      "amr": ["passkeys"]
    }
  },
  "resource": {
    "type": "mcp-tool",
    "id": "mcp:expenses"
  },
  "action": {
    "name": "fintech_approve_expense",
    "properties": {
      "expense_id": "exp-123",
      "amount": 5000
    }
  }
}

AuthZEN Evaluation Response

The PDP returns a decision:

{
  "decision": true
}

Or:

{
  "decision": false
}

When decision is true, the MCP Server proceeds with request execution. When decision is false, the MCP Server MUST return HTTP 403 Forbidden.

Benefits

Benefit	Description
Standardization	AuthZEN provides a vendor-neutral interface, avoiding PDP lock-in
Externalized Authorization	Policy decisions decoupled from application code
Fine-Grained Access Control	Support for ReBAC, PBAC, ABAC, or hybrid models
Policy as Code	Policies managed as versioned artifacts with audit trails
Centralized Governance	Consistent policy enforcement across MCP deployments
Dynamic Authorization	Runtime evaluation of context-aware policies
Interoperability	Compatible with any AuthZEN-compliant PDP

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 ext-auth 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.

[tulshi]

Thanks for putting this together! I think extracting the context in an MCP request is the key part (item modelcontextprotocol/modelcontextprotocol#3 in the Authorization Flow architecture steps). In your example, you suggest using the tool name as the resource identifier, but that level of control could be asserted using an OAuth token scope. In order to become more fine-grained than that, we would need a way to predictably parse an MCP request into an AuthZEN API request. Something for us to think about both in the MCP community and in the AuthZEN WG.

[baboulebou]

This is great Martin. Great start. Just one minor correction in your proposal: AuthZEN is an official 1.0 specification now, not an implementer's draft anymore.

As Atul mentions, mapping MCP requests into fine-grained AuthZEN request will likely be an AuthZEN profile for MCP extension to AuthZEN within the AuthZEN WG, but this here lays the groundwork for this type of integration.

[davidjbrossard]

I agree with all the aforementioned points. I'll add that adopting AuthZEN is inline with NIST best practices and follows the architecture described in:

• NIST ABAC 800-162
• NIST Zero Trust 800-207

Also, using AuthZEN for MCP opens the opportunity to apply the same consistent access control "policies" across an entire IT stack (AI of course but also APIs, web apps, and more)

[nbarbettini]

Hi @embesozzi, thanks for putting together this proposal. I like AuthZEN, but it's not clear to me what should change in the protocol here. Any MCP server could choose to use AuthZEN in the way you're describing here today - nothing new required! Is the recommendation of a non-normative pattern the thing you want to formalize? Or something that will require protocol- or client-level support?

We are also looking at fine-grained authorization in the MCP working group I am facilitating, from the perspective of what an MCP client needs to understand authorization decisions or requirements. It would be great to collaborate!

[embesozzi]

Hi @nbarbettini, thanks for the feedback!
Yes, any MCP can act as an AuthZEN PEP, communicating with an AuthZEN PDP. As Atul mentioned before (Atul and David are authors of the spec, and Alex is a contributor), we can work together - the AuthZEN WG and the MCP community - to define an AuthZEN profile for MCP. This would specify how to parse an MCP request into the AuthZEN information model, which would help simplify and guide how MCP servers can easily become AuthZEN clients.
On the other hand, if the MCP community agrees, we can also formalize the use of OpenID AuthZEN as an MCP authorization extension.

Nevertheless, the main idea was to start discussing this approach, and we’d love to get feedback from the MCP community.

[D1skin]

thanks for putting this together @embesozzi , we at Delinea are following the AuthZen work very closely and appreciate it greatly.

I tend to agree with @nbarbettini - I like AuthZen but it doesn't seem to require a change in MCP protocol per se.

I also agree @tulshi 's points are very valid - I think AuthZen should aspire to map beyond the tool level. Ideally what MCP authorization needs in my perspective:

1. addressing correlation to the resources and actions in the end system exposed by the MCP there in order to create a correlated one central policy. (eg not just tool:fetch_customer_record but {action:read, target:customer_record_for_account_12345} which would enable mapping those also to policies for other apps)
2. correlating identities in a way that allows to map the end systems access level to identity or permission system - right now too many MCP implementations rely on limited identification of the delegating user that initiated the task and/or acting using a very privileged account in the end system.
   Handling these two would solve a real significant problem where the AuthZen separate PDP architecture would shine in my opinion and also where it can also share authorization across different apps

[localden]

Thanks for writing this out, @embesozzi. As it was mentioned in this thread, I don't believe there is anything here that needs to be directly integrated into the protocol.

If in the future there is a desire to make this an authorization extension (seems to be the most natural path), then this needs to be something that is first worked together with the auth interest group (you can find it in our Discord under #auth-ig).

To keep the discussion more focused and less intermingled with the core protocol pieces, would recommend that we move the issue to ext-auth and keep the discussion there (along with #auth-ig).

[embesozzi]

Hi @localden, thanks for the feedback.
Sounds good to move the ticket, and I’m happy to continue the discussion in the #auth-ig channel if the group is interested.

[tulshi]

Please take a look at my related proposal: #15

[sberyozkin]

If I understand it correctly, the ext-auth repository is about various extensions for MCP clients to acquire tokens as apposed to how these tokens are verified at the MCP server level.

I support the idea, but not sure if having this draft at the same level where for example a client_credentials extension is introduced would not be confusing - though the core protocol talks about how MCP server should verify tokens, perhaps there should be subsections in this repository's README at https://github.com/modelcontextprotocol/ext-auth?tab=readme-ov-file#extensions