MCP and Agent Security

MCP and OAuth: Securing the Trust Anchor

By CyberSec42 Research · Updated 2026

Securing the OAuth trust anchor in MCP comes down to pinning and validating four things server-side: the authorization server, the origin of the protected resource metadata, the requested scope, and the token's audience. MCP adopted OAuth 2.1 as its authorization layer and inherited a whole class of trust-root errors with it. This class has the highest leverage of all MCP risks, because a single library defect reaches every dependent server.

Why OAuth in MCP becomes a target

In MCP, OAuth 2.1 governs which client may access a resource server with which rights. The trust anchor is the question of whom the client believes when it learns where to go for authorization. That is exactly where the problem lies: the pointer to the authorization server and the resource metadata often comes from a server-controlled WWW-Authenticate header. If the client or server takes that pointer without pinning origin and issuer, a malicious or interposed resource server can redirect the grant to its own infrastructure, harvest the issued token, or inject an overly broad scope into the consent.

That is what makes this class so delicate: the vulnerable point does not sit in a single server, but in the shared libraries and SDKs underneath. This is why the attack front has moved from individual servers to those libraries. A defect there is inherited by every downstream server, without its operator having made a mistake of their own.

The four checkpoints in detail

1. Pin the authorization server origin

The client must not take the authorization server blindly from a value the resource server influences. The origin of the authorization server belongs pinned server-side or set to a fixed allowlist. If the client instead adopts an arbitrary authorization_server_url, an attacker can redirect the entire token flow to their own infrastructure. That is a classic confused deputy: the client hands over the resource token while trusting an unverified origin.

2. Check the PRM origin against the resource origin (RFC 9728)

RFC 9728 describes how a client finds the protected resource metadata of a resource server. The security rule with it: a resource_metadata pointer is honored only if its origin equals the origin of the resource server. Without this same-origin check, a server can point at foreign metadata and steer the client to a substituted authorization server. The check has to be real origin equality, comparing scheme, host, and port, not a loose prefix check.

3. Intersect the scope with the entitlement

A client should only get the scope it is actually entitled to. If the scope named in the request is adopted verbatim into the consent, an attacker can inject an overly broad scope and obtain rights that go far beyond the use case. The right approach is the intersection: the granted scope is the requested scope intersected with the client's entitlement, deny by default. That limits the damage even when part of the flow was tampered with.

4. Validate the token audience

An access token carries an audience that names the intended recipient. If the aud claim is not validated, a resource server accepts a token that was issued for a different service. Validating the audience makes sure a token captured in one place cannot be reused in another. Together with the intersected scope, that significantly limits an attacker's lateral movement.

Why this class so often escapes reviews

The trust anchor lives between the components, not inside a single one. A review that only reads the server code sees the correct handler and misses that the origin of the authorization pointer was never pinned. What makes it harder is that the actual weakness often sits in a shared library that many servers use in common. Anyone checking only their own repository does not find the bug, even though their own server inherits it. The check only becomes reliable when it looks at the flow across the boundaries and tests each of the four checkpoints against a defined invariant.

Frequently asked questions