MCP Resource Indicators: What Your Bot's OAuth Tokens Must Specify

The resource-indicator requirement

For MCP clients using HTTP OAuth authorization, the specification requires Resource Indicators for OAuth 2.0, as defined in RFC 8707, to name the target resource a token is being requested for. The resource parameter must appear in both the authorization request and the token request, must identify the specific MCP server the client intends to use the token with, and must use that server's canonical URI rather than a broader domain or a wildcard. MCP authorization itself remains optional for implementations.

This is a hardening, not a suggestion. As the MCP lead maintainer put it when the requirement landed in the draft spec, resource indicators are no longer optional, and client developers are now required to implement RFC 8707. That phrasing matters for anyone maintaining an MCP client today: a client that skips the resource parameter is no longer just missing a nice-to-have, it is out of spec.

The practical effect is that each OAuth request in this flow carries an explicit statement of intent. A client is not asking an authorization server for 'a token that can talk to MCP servers in general.' It is asking for a token scoped to one named server. Whether the resulting token is actually restricted to that server also depends on the authorization server honoring the parameter and the MCP server checking the token's audience.

Sources: Authorization - Model Context Protocol, Update To MCP Authorization Spec - Resource Parameter (RFC 8707) | Den Delimarsky.

Why this closes a real phishing-shaped gap

The change traces back to a phishing-style scenario raised against the MCP repository. In the illustrative version the lead maintainer used to explain it: a person searches for an MCP server to manage travel plans, lands on a page that looks legitimate, and is told the server that books hotels lives at a particular URL. The person authorizes their bot to connect. If the token issued during that flow could be replayed against a different server, the wrong site could end up holding a working credential, even though the person only ever meant to authorize one destination.

Requiring the canonical URI of the target server in the resource parameter lets an authorization server bind the token to that destination at issuance time. This only closes the replay path when the authorization server honors the parameter and the receiving MCP server rejects tokens issued for another audience. The client parameter alone is not a complete defense.

This kind of problem has a name in the wider identity world: a confused deputy attack, where a credential meant for one purpose gets used for another because nothing checked that the purpose matched. MCP's resource parameter requirement is a targeted fix for that specific shape of failure, applied to the tool-connection pattern that MCP formalizes.

Sources: Update To MCP Authorization Spec - Resource Parameter (RFC 8707) | Den Delimarsky, Authorization - Model Context Protocol.

A worked example: two MCP servers, one bot

This is illustrative, not a real deployment. Say a personal bot is connected to two MCP servers: one that manages a calendar, one that files expense reports. Both authorization servers sit behind the same identity provider, because that's convenient to set up and is a common pattern for small teams running more than one internal tool.

Without a resource parameter, a token issued during the calendar connection might carry no explicit audience, or a broad one that just names the identity provider. If the expense server accepts any token from that identity provider without checking who the token was actually issued for, the calendar token could be replayed there. Nothing about the token itself would look wrong in isolation; it would just be handed to a service it was never meant to reach.

If the authorization server honors the resource parameter, the calendar token's audience names the calendar server's canonical URI. The expense server, receiving that token, checks the audience, sees it does not match its own URI, and rejects it. In this correctly configured example, a wiring mistake or deliberate replay attempt fails at the audience check.

What to check before you trust a connection

The requirement only protects you if both sides implement it correctly. A client sending the resource parameter does nothing if the server on the other end ignores the audience claim it receives, or checks it loosely enough that a near-match passes.

• Does the client send a resource parameter in both the authorization request and the token request, naming the MCP server's canonical URI?
• Does the server validate the token's audience claim against its own canonical URI, using exact matching rather than a prefix or wildcard match?
• Does the setup reject a token that arrives with no audience claim at all, rather than treating a missing claim as implicitly valid?
• If you operate more than one MCP server behind the same identity provider, has each server's canonical URI been registered distinctly, so tokens for one cannot be mistaken for another?

Sources: Authorization - Model Context Protocol.

Timeline and current status

The resource-indicator requirement was described by MCP lead maintainer Den Delimarsky on June 18, 2025. It is not a new requirement from the July 2026 specification release. That later release made other protocol and authorization changes, as the maintainers' release post and roadmap describe.

The specification still requires the client to send the resource parameter and the MCP server to validate that tokens were issued for it. Den also noted an implementation limit when the requirement was introduced: an authorization server that does not support the parameter may ignore it. Sending the parameter does not, by itself, prove that a token is audience-bound.

If you are building or reviewing an MCP connection, check the current specification revision and test the full flow: client request, authorization-server token issuance, and MCP-server audience validation. BotBento is in development and does not currently offer an automated connection review for this check.

Sources: Update To MCP Authorization Spec - Resource Parameter (RFC 8707) | Den Delimarsky, Authorization - Model Context Protocol, The 2026-07-28 Specification | Model Context Protocol Blog, The New MCP Roadmap | Model Context Protocol Blog.