Mastering Secure APIs and AI Agents with Zero Trust and Fine-Grained Authorization Based on OpenID AuthZEN

This article was originally published on Medium.

A practical guide to standardizing authorization for APIs, MCP servers, and AI-powered interactive applications.

This paper presents the results of extensive work. I decided to structure it around a single paper in which you determine the technology to protect, such as APIs, agents, or MCP/MCP Apps.

Table of contents

The Hardest Problem in Building Secure Platforms

Authorization remains one of the most challenging and often underestimated aspects of building secure platforms. While authentication- proving who you are - has been largely solved through standards like OpenID Connect and passkeys (see the FIDO Alliance for more information), authorization - determining what you can do - continues to fragment across proprietary implementations, homegrown solutions, and tightly coupled application logic.

The emergence of AI agents changes everything. With the Model Context Protocol (MCP), AI assistants can now dynamically discover and invoke arbitrary tools across multiple servers. MCP Apps extends this further, enabling interactive user interfaces delivered directly within AI conversations.

Traditional authorization approaches struggle with three fundamental problems:

1. Poor interoperability leading to vendor lock-in: Each authorization system speaks its own language, making it impossible to switch PDPs or integrate across platforms without significant rework.

2. Growing complexity that doesn’t scale: As systems expand, authorization rules multiply exponentially. Embedded logic becomes unmaintainable and inconsistent across services.

3. Tight coupling of authorization logic in application code: When policies live inside application code, every policy change requires development cycles, testing, and deployment, a recipe for security drift and technical debt.

The solution? AuthZEN an OpenID Foundation standard that finally addresses authorization interoperability.

What is AuthZEN?

The OpenID Foundation AuthZEN Working Group has developed and approved the Authorization API version 1.0. This is a stable version of a specification providing intellectual property protections to implementers - this is production-ready technology with industry backing.

AuthZEN standardizes the communication interface between Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs). If you’re familiar with the XACML standard from years past, think of AuthZEN as its modern, REST-native successor - simpler, lighter, and designed for today’s distributed architectures.

The concept is elegant in its simplicity: instead of embedding authorization logic in every application, you externalize decisions to a dedicated policy engine. The PEP - whether it’s an API gateway, MCP server, or application component - asks the PDP a simple question: “Should this subject be allowed to perform this action on this resource?”

The PDP encapsulates all the complexity of policy evaluation. It might check role memberships, evaluate attribute conditions, traverse relationship graphs, or apply custom business rules. The PEP doesn’t need to know how the decision is made, it only needs to enforce the result.

Core Benefits

• Interoperability: Connect any AuthZEN-compliant PDP such OpenFGA, Cerbos or Alfa Axiomatics without changing application code
• Decoupled authorization: Policy decisions separated from enforcement logic
• Flexibility: Support multiple authorization models (ReBAC, PBAC, ABAC) with the same interface
• Policy as code: Manage policies as versioned artifacts with audit trails
• Dynamic evaluation: Runtime context evaluation for adaptive authorization

The AuthZEN Evaluation Request

Every AuthZEN request follows a consistent structure with four primary components:

{
 "subject": {
   "type": "",
   "id": "",
   "properties": {}
 },
  "resource": {
    "type": "",
    "id": "",
    "properties": {}
 },
  "action": {
   "name": "",
   "properties": {}
 },
  "context": {}
}

The PDP evaluates this request against its policies and returns a decision:

{
 "decision": true
}

Or:

{
 "decision": false
}

That’s it. A standardized question and a standardized answer. The complexity of policy evaluation, whether it involves checking relationships, evaluating attributes, or running policy rules, is entirely encapsulated within the AuthZEN PDP.

API Security with AuthZEN

Before diving into AI-specific scenarios, let’s establish how AuthZEN transforms API security. The pattern is straightforward: an API gateway acts as the PEP, intercepting requests, extracting context, and consulting the PDP before allowing operations to proceed.

The gateway extracts subject information from JWT claims, determines the resource and action from the HTTP request, and constructs an AuthZEN evaluation request. The PDP, whatever implementation you choose, evaluates the request and returns a decision.

API Security PBAC Example: Policy-Based Access Control

Consider a financial services requirement:

Only admin users authenticated with a phishing-resistant authenticator can access confidential documents based on their roles and tenant

A phishing-resistant authenticator, such as passkeys, is indicated by the acr (Authentication Context Class Reference) claim containing inherence and the amr (Authentication Methods References) claim containing passkeys.

Here’s how you’d configure the gateway plugin:

When a request arrives, the gateway:

• Extracts preferred_username, roles, tenant, acr, and amr from the JWT
• Builds an AuthZEN request with the resource set to the HTTP URI and action as the HTTP method
• Sends the request to the AuthZEN PDP

4. AuthZEN PDP evaluates whether the policy allows the action for this user

5. The gateway enforces the decision

MCP Security: Fine-Grained Authorization for AI Tool Invocation

APIs are just the beginning. The Model Context Protocol (MCP) enables AI agents to discover and invoke tools dynamically across multiple servers. This introduces authorization challenges that OAuth scopes alone cannot address.

Why OAuth Scopes Fall Short for MCP

OAuth scopes operate at broad permission levels - read, write, admin. But MCP requires granular decisions:

• Can this user invoke fintech_approve_expense with amount $5000?
• Can this analyst delete expenses, or only view and approve them?
• Should step-up authentication be required for high-value operations?

These questions involve runtime context, resource attributes, and complex policy logic that scopes cannot express.

Scopes are determined at token issuance time and cannot adapt to runtime context. A scope like expenses:write grants broad permission, but it cannot distinguish between approving a $100 expense and approving a $100,000 expense. It cannot enforce that analysts can only approve expenses in their assigned department. It cannot require step-up authentication for high-risk operations.

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:

The MCP server first validates the OAuth token (401 on failure). Then, it extracts context from JWT claims and the MCP request, builds an AuthZEN evaluation request, and queries the PDP. Only if the PDP returns “decision”: true does the server execute the requested tool.

MCP Security: Expense Approval

In this example we are going to configure the gateway to supports dynamic MCP request mapping:

Key features:

• mcp::tool::name: Dynamically extracts the tool name from the JSON-RPC body
• *mcp::tool::arguments: *: Extracts specific tool arguments
• enforce_on.methods: Configures which MCP methods trigger policy enforcement

So, given this MCP request:

And a JWT containing:

The gateway constructs this AuthZEN request:

The PDP can now evaluate complex policies: Is this user an analyst? Are they authenticated with a phishing-resistant authenticator? Is the amount within their approval limit? Is the expense in their assigned department?

Important: The MCP Mapping described above 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.

Considerations:

• Subject sources: While this example derives subject information from JWT claims, AuthZEN is flexible about subject sources. Depending on your deployment architecture, subject information can come from other sources - the key is that the PEP constructs a consistent AuthZEN request regardless of where the data originates.
• PDP data enrichment: The AuthZEN PDP is not limited to the data provided in the evaluation request. The PDP can retrieve and incorporate external data sources (user directories, relationship graphs, resource metadata) when making policy decisions. This enables sophisticated authorization scenarios without bloating the evaluation request.

MCP Apps: Securing Interactive AI Experiences

MCP Apps (Model Context Protocol Apps Extension - SEP-1865) represents a paradigm shift in how AI agents interact with users. While base MCP standardizes tool invocation, MCP Apps extends this to deliver interactive user interfaces directly within AI conversations.

Think about what this means: instead of text-only responses, AI assistants can render forms, dashboards, buttons, and interactive elements. Users can approve expenses, view charts, click actions , all within the AI conversation flow. The AI host (Claude, Copilot or other compatible clients) renders rich UI components directly in the conversation.

This changes everything about authorization. It’s no longer just about whether a user can invoke a tool, it’s about whether they can see certain UI elements, click specific buttons, and perform interactive actions.

Why MCP Apps Changes the Authorization Game

Traditional MCP authorization answers: “Can this user invoke this tool?” MCP Apps requires answering more nuanced questions:

• Can this user see the “Delete” button in the expense dashboard?
• Should the “Approve” button be enabled for expenses over $10,000
• What happens when an unauthorized action is attempted through the UI?

The authorization flow remains the same, AuthZEN evaluation requests to a PDP, but the integration with interactive UI elements creates a more responsive user experience. Users receive immediate feedback about what they can and cannot do, rather than encountering errors after attempted actions.

Security MCP App: Fintech Expense Management

Consider a financial services company deploying an AI-powered expense management system:

• AI assistants help employees manage expenses through natural conversation
• Interactive dashboards display expense lists with action buttons (not just text)
• Policy-driven access controls who can view, approve, and delete expenses

The security requirements:

Additionally, all users must authenticate with a phishing-resistant authenticator (passkeys).

Case 1 MCP App: View Expenses as Analyst

a) User prompt: “Please list the expenses”

b) AI Assistant action: Calls fintech_list_expenses tool

c) MCP Gateway flow:

• Extracts JWT claims (sub, roles, acr, amr)
• Retrieves the MCP tool name from the JSON-RPC body
• Verifies the method is tools/call
• Sends AuthZEN evaluation request to PDP
• PDP evaluates: User is analyst, authenticated with passkeys, action is list → ALLOW
• Gateway forwards request to MCP Server

Result: User sees an interactive expense dashboard with action buttons (Approve, Delete)

Case 2 MCP App: Approve Expense as Analyst

a) User action: Clicks “Approve” button on expense #123 in the MCP Apps UI

b) AI Assistant action: Calls fintech_approve_expense(123)

c) MCP Gateway flow:

• Same context extraction process
• AuthZEN request with action fintech_approve_expense
• PDP evaluates: User is analyst, authenticated with passkeys, action is approve → ALLOW
• Gateway forwards request

Result: Expense approved, user sees success confirmation in the interactive UI

Case 3 MCP App: Delete Expense as Analyst

a) User action: Clicks “Delete” button on expense #123

b) AI Assistant action: Calls fintech_delete_expense(123)

c) MCP Gateway flow:

• Same context extraction
• AuthZEN request with action fintech_delete_expense
• PDP evaluates: User is analyst (not admin), action is delete → DENY
• Gateway returns 403 Forbidden

Result: User sees error message “You don’t have permission to delete expenses”

The MCP Apps UI can render this gracefully, showing a contextual error message when the action is attempted.

Live Demo:

Multi-Layer Security Architecture

Enterprise MCP deployments typically involve multiple PEPs at different trust boundaries:

Here is an implementation in which PEP #1 (an AuthZEN MCP Gateway) enforces authorization at the MCP layer by communicating with an AuthZEN PDP, and PEP #2 (an API Gateway) enforces fine-grained, resource-level policies closer to the API.

The MCP server and the API can also act as AuthZEN PEPs, and you can use multiple AuthZEN PDPs with different authorization models. Additionally, you can combine CGA at the MCP/Gateway level with FGA applied deeper in the request journey.

Zero Trust Architecture for AI Applications

The patterns described throughout this article align with Zero Trust principles: never trust, always verify. Every request, whether from a human user or an AI agent, must be explicitly authorized based on all available context.

Benefits of AuthZEN for AI Security

Policy as Code and Governance

Once AuthZEN is adopted, organizations should follow a policy-as-code approach:

• Store policies in version control alongside application code
• Apply code review processes to policy changes
• Test policies in staging environments before production deployment
• Implement policy governance workflows for sensitive changes
• Maintain audit logs of policy decisions for compliance
• The AuthZEN standard makes this possible by separating policy definition (in the PDP) from policy enforcement (in the PEP).

Conclusion

Authorization is heading in a clear direction: standardized, decoupled, and interoperable. The OpenID Foundation AuthZEN specification provides the foundation for this transformation, and AI applications, with their dynamic, context-rich interactions. are accelerating the need for adoption.

The patterns demonstrated in this paper work today:

• API Security: Deploy an AuthZEN-compliant gateway PEP in front of your APIs
• MCP Security: Extend the same gateway to handle MCP tool invocations with dynamic context extraction
• MCP Apps Security: Secure interactive AI experiences with fine-grained, policy-driven authorization

Thanks to interoperability, the sky is the limit.

What excites me most about this direction is how it changes the conversation around AI security. Instead of debating whether AI agents are “safe enough” to deploy, we can focus on building the right policies and enforcing them consistently. The authorization is the core product, not a secondary feature.

If you’re building AI-powered applications today, consider how AuthZEN can simplify your authorization architecture. The specification is stable, implementations are available, and the patterns work across both traditional APIs and emerging MCP-based AI workflows.

Important Personal View: When you talk to AI security “experts”, you’ll hear about lots of custom implementations, please don’t go down that road. I firmly believe in open security standards, which is why this entire approach is based on them. See below.

If you’re curious about implementing AuthZEN for your API or AI applications, or want to discuss MCP Apps security patterns, open security standards, I’d be happy to connect.

Other Related Articles

[a] AuthZEN: Standardized Authorization for API and AI Security

[b] Securing MCP Apps with the AuthZEN MCP Gateway: Fine-Grained Authorization for Interactive AI Experiences

[c] Agentic AI Security: Protecting Interactive Keycloak MCP App with OpenID AuthZEN Gateway for FGA

[d] TwoGenIdentity - Security Blog

References

[1] OpenID Foundation AuthZEN Working Group

[2] AuthZEN Authorization API 1.0

[3] TwoGenIdentity API/AI AuthZEN Gateway