OAuth resource indicators for remote MCP security

Use a resource indicator to name the intended MCP server

An OAuth resource indicator answers a narrow question before a token is issued: which protected resource is this token for? RFC 8707 defines the resource request parameter as an absolute URI without a fragment. The authorization server can use that identifier to apply policy and audience-restrict the resulting access token. The current MCP authorization specification makes this behavior mandatory for clients: send resource in both the authorization request and token request, and identify the MCP server with its canonical URI.

Resource binding and permission scope solve different problems. Scope describes what the token may do; the resource indicator identifies where it may be used. A token can have an apparently suitable scope and still be invalid at a server whose audience it does not name. For MCP, the server must validate that the token was issued specifically for its own resource and return HTTP 401 for an invalid or expired token.

Client request

resource=https://mcp.example.com/mcpSend the same canonical target in the authorization and token requests.

Authorization result

A token restricted to the intended resourceThe authorization server decides the accepted identifier and how it represents the audience.

Server decision

Accept only a token intended for this serverScope alone is not a substitute for audience validation.

Keep discovery metadata and the resource URI aligned

A remote MCP client first needs a trustworthy way to learn which authorization server serves the protected resource. The current MCP discovery specification requires protected resource metadata with at least one authorization_servers entry. A server can point to that metadata in a WWW-Authenticate challenge on a 401 response or publish it at the RFC 9728 well-known location. Clients must support both paths, preferring the challenged metadata URL when one is present.

The metadata resource value is an identity check, not a decorative label. RFC 9728 requires it to be identical to the protected-resource identifier used to construct the well-known URL, or, for challenge-directed discovery, identical to the URL used for the resource request. A mismatch means the metadata must not be used. This is why a deployment at https://host.example/mcp may need the path in its resource identifier rather than a host-only value that identifies a different resource.

Discover

Read resource_metadata from the challenge or probe the well-known URIDo not invent an authorization-server location from an unrelated endpoint.

Validate

Compare the returned resource value with the requested resourceReject metadata when the protected-resource identity does not match.

Select

Use an authorization server listed by the validated metadataContinue only after the protected-resource identity check succeeds.

Send one precise canonical resource through the flow

Start from the actual MCP endpoint the client will call. The MCP specification recommends the most specific URI available and shows that a path can distinguish an individual MCP server. RFC 8707 permits multiple resource parameters, but it encourages a single resource where possible because a multi-audience bearer token is usable by more than one recipient and requires a high degree of trust among them. For a single remote MCP server, one precise identifier is the safer review default.

Preserve that identity across authorization, code exchange, and refresh. RFC 8707 allows an authorization server to restrict a token request to resources that were in the original grant and explains that resource-specific downscoping can reduce disclosure of unrelated permissions. Do not assume the token literally contains the requested URI: the authorization server may map the resource value to another audience representation. The validation contract must therefore be documented between the authorization server and MCP resource server.

Prefer

One network-addressable, path-aware resource URIInclude a path when it identifies the particular MCP server or tenant.

Avoid

Generic audiences such as api or a host shared by unrelated servicesA broad identifier weakens the boundary that the resource parameter is meant to express.

Document

The authorization server's audience mappingJWT aud, token introspection, or another verified mechanism may carry the decision.

Reject missing, wrong, or unverifiable audiences

The resource server is the final enforcement point. For a JWT access token that follows RFC 9068, the server must verify that aud contains an identifier it expects for itself and reject the token otherwise. For an opaque token, the server needs a trusted validation contract, such as authorization-server introspection, that establishes the intended audience. In either case, the current MCP requirements say the server must verify that it is the intended recipient before processing the request or returning protected data.

Test negative cases, not only a successful sign-in. A useful suite presents a token for another API, a token with no audience, a malformed token, an expired token, and protected resource metadata whose resource does not match the MCP endpoint. The current Model Context Protocol TypeScript SDK conformance client registers an auth/resource-mismatch scenario that expects discovery to stop before token exchange when protected resource metadata names the wrong resource. That source demonstrates a maintained test path, not proof that every client or server passes it.

The unique deliverable for this review is a negative-test matrix tied to exact resource identifiers. Record the requested MCP URL, discovered metadata resource value, authorization-server mapping, token audience representation, and result at the resource server. A wrong-resource token and mismatched metadata must fail before any protected tool runs. That evidence is more specific than a general statement that token forwarding is unsafe.

Wrong audience

Reject before any MCP operationA valid signature and useful scope do not make a token valid for this resource.

Missing audience

Fail closed unless an equivalent trusted recipient check existsRecord which validation mechanism establishes the intended server.

Metadata mismatch

Stop discovery before token exchangeDo not continue with authorization metadata bound to a different resource.

Review the boundary with a concrete two-service failure case

Suppose one authorization server issues tokens for both https://files.example/mcp and https://billing.example/mcp. A client requesting the files server should send only the files URI as resource. If it later presents that token to billing, billing must reject it because the token was not intended for that audience. If billing accepts the token merely because the issuer and signature are familiar, the deployment has lost the cross-service boundary that resource indicators are designed to create.

The same review applies when an MCP server calls an upstream API. The current MCP security considerations require a separate upstream token and forbid passing through the token received from the MCP client. Resource binding establishes an intended recipient; it does not authorize forwarding the inbound token. Keep token storage, permission scope, and the other OAuth controls as separate review decisions.

This example tests recipient identity only. After billing rejects the files token, a separate review still has to determine whether either server forwards credentials upstream. Resource indicators make the wrong-recipient test possible; they do not by themselves prove upstream-token separation, scope minimization, or safe storage.

Files token at files

Audience matchesContinue only after token validity and intended-audience checks succeed.

Files token at billing

Audience mismatchReturn an authorization failure without invoking billing tools.

MCP server to upstream API

Use a separately issued upstream credentialNever turn the inbound MCP bearer token into a downstream passthrough credential.

Continue the remote MCP authorization review

Resource indicators are one control in the authorization chain. Review the broader security directory for endpoint identity, scopes, credential storage, transport, and revocation. Then examine token passthrough separately so an audience-bound client-to-server token is never mistaken for permission to call a downstream service.

Evidence boundary and current coverage gaps

Recent practitioner evidence is useful as an implementation signal, not as prevalence or interoperability proof. A July 2026 LiteLLM pull request describes carrying RFC 8707 resource indicators through authorization, token exchange, refresh, client credentials, token caching, and per-user OAuth identities. Its discussion also records a reviewer finding about user information in a resource URI and a query-string variant. These are project-maintainer statements from one change set; this research did not reproduce the implementation or independently verify its security review.

Do not treat this draft as a compatibility benchmark, a cross-client conformance result, or proof that a particular deployment enforces audience binding correctly. Before relying on an implementation, independently inspect its protected resource metadata and authorization-server configuration, verify the expected audience representation, and run negative tests with wrong-resource, missing-audience, expired, and malformed tokens. Repeat those checks for every client, server, issuer, endpoint path, and tenant boundary in the intended deployment.