Security in and around MCP: Part 1 — OAuth in MCP

Read full article from Maia Iyer here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-1-oauth-in-mcp-3f15fed0dd6e/?utm_source=nhimg

Read part 2 here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-2-mcp-in-deployment-65bdd0ba9dc6/?utm_source=nhimg

Read part 3 here:  https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-3-mcp-server-identity-10d6768d96c1/?utm_source=nhimg

As enterprises experiment with the Model Context Protocol (MCP) to connect AI agents with tools, a pressing question emerges: how do we maintain security at scale? MCP simplifies the mechanics of exposing and consuming tools, but it also raises new identity and access challenges. If agents act on behalf of users or services, what stops privilege escalation? How do we avoid insecure handling of credentials? And how should clients, servers, and downstream tools authenticate each other?

In this series, we’ll unpack these issues step by step. Part 1 focuses on OAuth in MCP, exploring why OAuth is the natural fit for agent–tool interactions and what implementers should watch for as adoption grows.

Quick Recap: What MCP Is and Why Security Matters

MCP follows a client-server model:

• The MCP Client (inside the host app, e.g., an LLM agent) connects to…
• An MCP Server, which proxies and exposes tools.
• The MCP Protocol defines communication between them.

This design avoids one-off integrations and enables an ecosystem of interchangeable servers. But because third-party servers can be plugged in easily, strong authentication and authorization are critical.

Recognizing this, the draft MCP spec already includes an Authorization section that builds on OAuth 2.0/2.1.

Why OAuth Belongs in MCP

OAuth allows an application to act on behalf of a user without directly handling user credentials. Instead of an agent storing passwords or API keys, a trusted OAuth server issues a short-lived access token that encodes identity and permissions.

This model has several benefits for MCP:

• Least Privilege: An agent only acts with the scope of its user, preventing escalation to capabilities the user doesn’t have.
• Short-Lived Access: Tokens expire, limiting the impact of leaks compared to static API keys.
• Mature Ecosystem: OAuth is widely deployed and supported with hardened libraries, reducing the risk of ad-hoc credential handling mistakes.

How OAuth Works in MCP

At the core is the access token, a signed set of claims from the OAuth server. It typically contains:

• iss (issuer) — the trusted authorization server.
• aud (audience) — which resource (e.g., ThisMCPServer) the token is intended for.
• exp — expiration time.

When the MCP Client makes a call, it presents this token. The MCP Server, acting as the resource server, verifies:

1. Signature validity against the OAuth server’s public keys.
2. Expiration (rejecting expired tokens).
3. Audience match (ensuring the token was issued for this server).

OAuth 2.1 and MCP’s Draft Standard

Today’s MCP Authorization draft recommends Authorization Code Flow with PKCE. For example:

• A helper chatbot (MCP Client) authenticates via OAuth to get a temporary access token.
• That token is attached to requests sent to the MCP Server.
• The server verifies the token before enabling tool usage.

This works well for straightforward scenarios (e.g., a single chatbot invoking a single MCP Server).

Where Things Get Tricky

The story doesn’t end there. Complexity rises when MCP is embedded in larger enterprise workflows:

• Chained Requests: What if the MCP Client is itself invoked by another service? How should delegation be managed?
• Multiple Tools: What if one MCP Server exposes tools with mixed security models (OAuth, API keys, SAML)?
• Interoperability: What if different servers and clients implement different OAuth flows or token formats?

These questions highlight why MCP’s use of OAuth is only the starting point—implementers must carefully design flows to avoid blind spots.

Key Takeaway

OAuth provides MCP with a well-understood framework for securing agent–tool interactions, enforcing least privilege, and replacing static credentials. But real-world MCP deployments will involve more complex trust chains, and securing those will require careful design beyond OAuth’s basics.