Securing MCP (Model Context Protocol) servers with OAuth 2.1: Architecture

Introduction

MCP (Model Context Protocol), unveiled by Anthropic in late 2024, represents a pivotal advancement in the AI ecosystem by standardizing the manner in which AI agents interface with external tools and data sources, making them more powerful, flexible, and easier to integrate.

A prominent organization we partner with required the development of MCP servers to integrate with their proprietary agents. After developing one or two prototype servers, the organization's next priority was to secure these endpoints through authentication and authorization, preferably using OAuth 2.1. For instance, a GitHub-based MCP might expose a tool for creating a repository branch. The agent must invoke this tool on behalf of a specific user, which necessitates a reliable authentication and authorization flow. Recognizing the requirement, I conducted an investigation into methods for embedding OAuth 2.1- based security into MCP servers.

This article provides a comprehensive overview of the architecture and terminology. In a forthcoming article, I will detail the implementation of a custom MCP server and its integration with an agent.

Understanding MCP

MCP is an open-source standard for connecting AI applications to external systems.

Using MCP, AI applications such as Claude, ChatGPT, or custom-built agents can seamlessly connect to a wide range of resources, including data sources (e.g., local files, databases), tools (e.g., search engines, calculators), workflows (e.g., specialized prompts), external APIs (e.g., GitHub REST APIs). This capability enables these systems to retrieve critical information and execute complex tasks efficiently.

For a comprehensive overview of MCP, please consult the official documentation: https://modelcontextprotocol.io/docs/getting-started/intro.

Having clarified the concept of MCP, we now turn our attention to MCP servers and MCP clients.

Understanding MCP servers

MCP servers are applications that expose specific capabilities to AI systems through standardized protocol interfaces. Typical implementations include file-system servers for document access, database servers for data queries, GitHub servers for code management, Slack servers for team communication, and calendar servers for scheduling.

For a comprehensive overview of MCP servers, please consult the official documentation: https://modelcontextprotocol.io/docs/learn/server-concepts.

Understanding MCP clients

MCP clients are instantiated by host applications to communicate with specific MCP servers. The host application, whether an AI platform such as Claude.ai or an integrated development environment like VS Code, governs the overall user experience and can coordinate multiple clients simultaneously. Each client maintains a single, direct connection with one server. Because the MCP protocol is expressly designed for AI agents to interact with third-party tools and services, an AI agent itself can function as an MCP client.

For a comprehensive overview of MCP clients, please consult the official documentation: https://modelcontextprotocol.io/docs/getting-started/intro.

The next step is to examine the workflow that unfolds when an MCP server protected by OAuth 2.1 is integrated into VS Code and invoked from a GitHub Copilot Chat query, or when a custom agent- e.g., one built with the Google ADK (Agent Development Kit) leverages the same MCP. If you have experience with web development and have previously implemented OAuth, most of the underlying mechanisms will be familiar. The section that follow will walk through the process in detail.

How OAuth 2.1 secures MCP server interactions in platforms like VS Code and custom agents

Please note that the architectural design and explanations presented here are largely inspired by the excellent article authored by Kevin Sapp. I have streamlined the steps to improve clarity, but for a more comprehensive treatment, please consult the original article: https://aembit.io/blog/mcp-oauth-2-1-pkce-and-the-future-of-ai-authorization/.

Architecture diagram

The diagram above, originally created by Kevin Sapp, illustrates the full authorization flow that underpins an MCP server protected by OAuth 2.1.

Workflow

• When a user poses a query or initiates a task, the MCP client/agent contacts the appropriate MCP server to invoke the requested tool, but does so without a valid access (Bearer) token, or with an expired token.
• The MCP server responds with HTTP 401 Unauthorized and provides a Protected Resource Metadata (PRM) URI in the WWW-Authenticate header. A PRM is a machine-readable JSON document that a protected resource (like an API) publishes to describe its authorization requirements and capabilities.
• The MCP client/agent retrieves the PRM document from the MCP server by accessing the designated PRM URI.
• The server returns a JSON payload that specifies the necessary authorization details, for example:

  {
    "authorization_server": "https://auth.example.com",
    "scopes": ["read:report", "tools:generate_summary"],
    "token_types": ["Bearer"]
  }

• Using the PRM data, the MCP client/agent issues an OAuth 2.1 Authorization Request to the designated Authorization Server. The server then authenticates the user via social login such as Google, Meta, Apple, traditional username/password or enterprise SAML/SSO providers like Entra ID, Okta, Auth0, OneLogin and presents a consent page in the user's default web browser.
• The resource owner grants consent for the requested scopes.
• The Authorization Server redirects the user's browser to the MCP client/agent's registered callback endpoint, delivering the authorization code.
• The MCP client/agent forwards the received authorization code to the authorization server in order to exchange them for a valid access (Bearer) token.
• The MCP client/agent re-issues the original tool-invocation request to the MCP server, this time including the newly acquired access (Bearer) token.
• The MCP server validates the bearer token, processes the request, and returns the authorized response to the MCP client/agent.

That concludes today's article. In an upcoming article, I will present a detailed implementation guide for a custom MCP server and demonstrate its integration with an agent.

---

About the author

Tirthya Kamal Dasgupta - System Engineer @ TCS

LinkedIn- https://www.linkedin.com/in/tirthya-kamal-dasgupta/

GitHub- https://github.com/tirthyakamaldasgupta

Email- [e-mail], [e-mail]

Feel free to reach out with questions, suggestions, or collaboration ideas.

If you found this article helpful, please feel free to like, share, or leave a comment. Your feedback is greatly appreciated and helps guide future deep‑dives!