Securing AI Interactions: Crossing the Hurdles of MCP Authorization

The rise of large language models (LLMs) and AI-powered applications brings incredible potential, but also poses significant security challenges. These applications have gotten much more useful with the emergence of agentic approaches and the ability to call out to different libraries, systems, and most importantly, to different APIs in order to take actions. They have moved from being a question answering resource to being able to do work, shop on your behalf, book travel, and update code. How can you ensure that the use of your APIs and systems is protected to the best degree possible?

The Model Context Protocol (MCP) aims to standardize interactions with systems leveraging context models, like LLMs. A crucial part of making this work in practice must be defining how authorization should work. The MCP Authorization specification provides a straightforward, standards-based approach using familiar technology: OAuth Bearer Tokens.

This blog post will explore:

  1. An overview of MCP Authorization.
  2. How Asgardeo's features map directly to the MCP Authorization requirements?
  3. An example scenario demonstrating a use case implementation.

Understanding the remote MCP access flow for authentication, authorization, and access delegation

The MCP specification outlines a client-server architecture, as shown in the diagram below:


 

Figure 1: High-level MCP architecture

The highlighted section in the diagram illustrates the MCP client accessing remote resources through a remote MCP server, which is the focus of our discussion. This discussion analyzes the specific authorization challenges inherent in facilitating remote communication with MCP. We will now dive into the detailed communication flows to see how authorization can be implemented.


 

Figure 2: MCP Authorization with remote access

  • MCP hosts: These are the applications users interact with, like IDEs (e.g., VS Code with an MCP plugin), specialized tools (like Claude Desktop), or custom applications that need access to data or AI capabilities via MCP.
  • MCP clients: Protocol-specific clients, embedded within the Host. An MCP client acts as an OAuth 2.1 client, making protected resource requests on behalf of a resource owner (the user). It manages the connection and communication with a specific MCP Server, handling the usage of access tokens. A Host might manage multiple Clients for different Server connections.
  • MCP servers: These are the backend services exposing specific capabilities (like accessing data, running models, interacting with APIs) using the MCP protocol. In OAuth terms, the MCP Server is the Resource Server.
    • Backend services: Resource systems (databases, web APIs, functions) accessible to an MCP Server, which can connect to.

The core interaction is between an MCP Client (within a Host) and an MCP Server. Securing this interaction is paramount.

Scenario: Accessing your pet's profile with the vet assist AI app

Let’s illustrate the challenges and how to secure access through a sample "Vet Assist AI” AI-powered app for informed and proactive pet care. It is implemented as an intelligent digital companion for pet owners, offering personalized and timely health and well-being information that enhances routine care and prepares owners for vet visits. The key capabilities include initial support, a knowledge base about pet health, and a reminder system for medication and appointments.

Let's say Bob (the User and a pet owner), is using the Vet Assist AI app (MCP Host) on Bob’s web browser. Bob wants to check the next vaccination date and book an appointment at the clinic for his dog, Fido. The AI Assistant needs to fetch this information by communicating via MCP with a Pet Profile MCP Server (a remote MCP Server). We need to ensure the assistant can only access Bob’s pet's data after Bob logs in and explicitly consent. Let’s see how to orchestrate this flow securely in the MCP context.

MCP authorization: Putting you in control with OAuth standards

The MCP Authorization relies on proven web security standards. We will use this sequence diagram to illustrate the sequence of interactions that will happen so that the app works securely:


 

Figure 3: User authentication, access delegation, and resource authorization

Bob starts chatting with the Vet Assist AI app and asks it to check the next vaccination date for Fido. The Vet Assist AI App (MCP Client/ OAuth Client) needs to access data (e.g., Bob's pet's profile) made available over the Pet Profile MCP Server (OAuth Resource Server).

To gain access, the Assistant starts an OAuth flow with the Authorization Server, specifying the necessary scopes. Authorization Server then requests Bob (the User) to log in and verifies if Bob's account has the required Roles/Permissions (RBAC) for the Assistant's intended action.

Importantly, the Authorization Server asks Bob for Consent, specifically whether Bob will allow the Assistant to check Fido’s profile (defined by the scopes) on Bob's behalf to view vaccination due dates. The Authorization Server should only issue an Access Token to the Assistant upon receiving Bob's consent. This token confirms the Assistant has Bob's permission for particular actions.

Subsequently, the Assistant (through its MCP Client) sends requests to the MCP Server, including Bob's Access Token. The MCP Server then validates this token by referring to JWKS information of Asgardeo, checking its signature, expiry, audience, and the granted scopes, before processing the request.

This is where an identity and access management (IAM) solution like Asgardeo shines. Asgardeo is a powerful, developer-focused, cloud-native IAM platform built on open standards like OAuth 2.0 and OpenID Connect (OIDC). It's perfectly suited to act as the Authorization Server required by the MCP Authorization spec.

Implementing with Asgardeo: Focusing on pet owner access

Bob needs to be sure that Fido’s info is not accidentally shared and that an AI agent doesn’t change its medications without the right controls. Let’s see how to add the right levels of protection to ensure this. We will do this with Asgardeo, an Identity-as-a-Service platform. To get an understanding of how to model access control levels, go to the Asgardeo console and follow along.

Define pet profile API resources, scope and roles

  1. Define API resource:
    • Register the Pet Profile MCP Server in Asgardeo as an API Resource (identifier: mcp-server://petprofile).


 

Figure 4: Register the MCP server as an API resource

  1. Define scopes (from Petstore API perspective):
    • pet:read: Permission for GET Pet information and related read operations.
    • pet:write: Permission for POST, PUT, DELETE on Pet. (We might restrict this for owners.)
    • (You can define others as needed.)


 

Figure 5: Configure scopes for MCP Server tools

  1. Define roles (RBAC):
    • pet_owner: Standard customer role.
    • vet_staff: Internal staff role (might have broader permissions).
  2. Assign scopes to roles: For the api://petprofile-mcp resource:
    • pet_owner role gets: pet:read and pet:write (only for their own pets - backend enforcement needed).
    • store_staff might get pet:read (all pets), pet:write, etc.


 

Figure 6: Assign Scopes to Roles

  1. Assign roles to users: Assign the pet_owner role to Bob's user account.


 

Register and implement MCP client

  1. Register client application: We will be manually registering the MCP client application in the Authorization Server, instead of using Dynamic Client Registration as suggested by the specification.

    • Register the Vet Assist AI (MCP Client) app.
    • This will configure an OAuth application for the MCP client with default configurations for:
      • Authorization Code Grant with PKCE
      • Public Client
      • JWT tokens
    • Set the redirect URL to an endpoint in the VetAssist AI app that can receive and process authorization code.


     

    Figure 7: Register Vet Assist AI app

    • Record Client ID.
    • Allow the app to request scopes pet:read. Let's assume owners cannot write pet data directly via the assistant, so the application doesn’t get pet:write.


 

Figure 8: Authorize the Vet Assist AI App to the Pet Profile MCP Server

  1. Implement OAuth/OIDC authorization grant code flow with PKCE in the MCP Client to integrate with Asgardeo for user authentication and obtaining tokens on behalf of the user.

We are done with the implementation, so now let's look at what the experience will look like at runtime.



 

MCP request & validation:

The Vet Assist AI application uses the MCP client to request Fido's information from the Pet Profile MCP Service, which acts as the MCP server. This interaction, as depicted in the MCP architecture diagram at the start of this document, underlies the authorization process. Essentially, Vet Assist AI, the MCP Host implementing the MCP Client, communicates with the Pet Profile MCP Service, the MCP Server, to access pet profile management features via MCP tools.


 

Figure 9: Authorization check at the MCP tool call

  1. The MCP Client (acting as the OAuth 2.1 client within the Assistant) sends an MCP request to the Pet Profile MCP Server to get Fido's details.
  2. Header: Authorization: Bearer
  3. The Pet Profile MCP Server (Resource Server) receives the request.
  4. Token Validation: It validates the token's signature, issuer, audience, expiry via Asgardeo's JWKS endpoint.
  5. Scope Check: It verifies the scope claim contains pet:read. Yes.
  6. User Context Check: The MCP Service uses the sub claim (bob_user_id) from the token.
  7. Authorization Granted: Validation passes. The service proceeds.
  8. The MCP Server sends the Fido's data back to the MCP Client
  9. The MCP Client forwards the data to the Vet Assist AI Host for display to Bob.

If Bob tried an interaction that triggers Vet Assist AI to use a function requiring, the assistant would request that scope. Since the AI Assistant app isn’t granted for it, Asgardeo would deny the authorization request upfront (won’t issue the scope pet:write for the token), and the MCP server would reject the token if it lacked the scope.

By implementing these steps, we have successfully secured the interaction between the Vet Assist AI app and the Pet Profile MCP Server, ensuring Bob's pet data is protected and securely shared with the Vet Assist AI. This setup demonstrates how Asgardeo, as an IAM solution, facilitates secure access and authorization for MCP-based applications.

How Asgardeo aligns with MCP security needs

The Model Context Protocol enables intelligent applications like the Vet Assist AI. By integrating Asgardeo as the OAuth 2.0 / 2.1 Authorization Server, you place security and resource owner control at the center. Asgardeo manages identities, enforces roles, captures explicit user consent, and issues tokens used by MCP clients (acting as OAuth 2.1 clients) to access protected resources. This ensures that applications acting on a user's behalf do so securely, transparently, and only with the necessary, user-approved permissions, building essential trust.

In short, Asgardeo supports MCP authorization through key capabilities:

  • Standard security: Natively supports OAuth specifications as required by MCP.
  • User control & RBAC: Requires user login and explicit consent for specific actions delegated to the client. And ensures users only delegate permissions they possess based on their roles.
  • Unified identity management: Manages users, applications (Clients), and resources (Servers) centrally. Defines boundaries: Clearly separates permissions (scopes) for different resources (MCP Servers) accessed by OAuth 2.1 clients (MCP Clients).
  • Developer focused: Simplifies secure integration for both MCP Client and MCP Server developers.

By leveraging standard OAuth protocols, robust user controls, and centralized identity management, Asgardeo ensures that AI applications access sensitive resources with appropriate permissions. This integration not only simplifies the implementation of secure MCP authorizations for developers but also places the resource owner firmly in control of their information, creating a transparent and protected ecosystem for AI-driven functionalities.

 

The agentic-app development space is evolving fast. We’re evolving just as fast with our agentic IAM capabilities.

If you're building agentic apps or looking to learn more about agentic IAM, join our early adopter program to get early access to what we’re building.

Join here: https://wso2.com/identity-and-access-management/ai/#early_access_program.