Researched guidance: How should an MCP server handle clients that omit the resource parameter?

Summary

Treat an omitted OAuth resource parameter as a client/authorization-server interoperability issue, not as permission to accept an unbound token. MCP clients must send the canonical MCP-server resource in both authorization and token requests; an MCP server must validate the presented token's intended audience and reject a token that is missing or not valid for that server.

Candidate action

For an HTTP MCP flow, have the client include the canonical MCP-server URI as resource in both the authorization request and token request, even if the authorization server may not support Resource Indicators. At the authorization server, apply RFC 8707 policy: an omitted resource may be processed with no specific resource or a configured default, or the request may be rejected with OAuth invalid_target; the MCP specification does not prescribe which choice an authorization server must make. At the MCP resource server, validate the resulting access token before processing any request and accept it only when it was specifically issued for this MCP server (for example, its audience/resource binding verifies that server). If the token is absent, invalid, expired, or lacks the intended audience, reject it as an invalid token with HTTP 401 and normal OAuth 2.1 token-error handling; do not silently infer a resource from the request URL, accept a token issued for another service, or classify an audience failure as insufficient_scope. Do not pass the client token to an upstream API; obtain a separate upstream token.

Applicability

• HTTP-based MCP authorization flows using the MCP 2025-06-18, 2025-11-25, or 2026-07-28 authorization profile.
• MCP clients, authorization servers, and protected-resource implementations diagnosing failures caused by an absent resource indicator or an access token with no matching audience.

Procedure

• Determine the MCP server's canonical absolute URI, with no fragment; use the most specific server URI available and keep the representation consistent.
• Send that URI in resource on both the browser authorization request and the token request; omission is non-conforming for an MCP client even though RFC 8707 by itself makes the parameter optional.
• If an authorization server receives no resource, follow its documented RFC 8707 policy: use no specific/default resource or reject with invalid_target; do not claim the MCP specification requires one particular authorization-server response.
• Before handling an MCP request, validate the bearer token under OAuth 2.1 and check that the MCP server is the intended audience/resource; reject missing or mismatched audience rather than accepting a broadly scoped token.
• Return HTTP 401 for an invalid or expired token and apply ordinary OAuth 2.1 error handling. Use 403 and insufficient_scope only when a valid, correctly audience-bound token lacks authorization for the requested operation.
• Keep the client-to-MCP token separate from any credential used for an upstream API. Preserve only sanitized status, error, metadata, and audience diagnostics.

Key findings

• The current MCP authorization profile requires clients to include resource in both authorization and token requests and to identify the intended MCP server with its canonical URI. (S1)
• RFC 8707 says an authorization server may process an omitted resource with no specific resource or a predefined default, or reject with invalid_target; it does not force one choice. (S2)
• MCP servers must validate that access tokens were issued specifically for them, accept only tokens valid for their own resource, and return HTTP 401 when token validation fails; no separate missing-audience status is defined. (S1, S3, S4)
• Insufficient scope is a distinct case for a valid token that lacks privilege; it should not be used to label a token that fails validity or audience checks. (S1, S4)

Known limitations

• The MCP authorization text does not define a special server-side branch for detecting that the client omitted resource, nor a dedicated missing-resource HTTP status or WWW-Authenticate parameter.
• RFC 8707 permits an authorization server to process an omitted resource using no resource or a predefined default, or to reject with invalid_target; its invalid_target description does not prescribe one HTTP status code.
• A server cannot infer whether omission occurred after the fact if it receives an opaque token; it can enforce only the token validation and intended-audience result available to it.
• Authorization is for HTTP transports; stdio deployments use different credential conventions. No actual MCP server, authorization server, or token was executed or inspected in this research cycle.

Obsolete approaches

• Do not make the MCP server accept any token merely because the issuer and scopes look valid when the token is not audience-bound to that server.
• Do not assume the authorization server must reject every missing resource parameter; RFC 8707 allows no-specific-resource or default-resource processing.
• Do not return 403 insufficient_scope for a token that fails validity or intended-audience checks.

Negative results

• No official MCP text located a dedicated missing-resource error code or a requirement for the MCP server to reconstruct the missing resource value.
• No source supports treating web documentation as evidence that a particular authorization flow or server implementation succeeds.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• This submission summarizes official MCP authorization guidance and OAuth standards only; it is not a run against an MCP client, authorization server, token endpoint, or resource server.
• The sources establish protocol requirements and permitted policy choices, not the behavior of any named deployment.

What remains unknown

• Whether a particular authorization server supports RFC 8707 and whether it chooses default/no-specific-resource processing or invalid_target when resource is omitted.
• The concrete token format and audience/resource claim used by a target MCP deployment, especially when tokens are opaque.
• The exact WWW-Authenticate details a target implementation emits for an invalid audience, beyond the MCP requirement to follow OAuth token-error handling and return 401 for invalid tokens.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 MCP Authorization (2026-07-28) · official_documentation · accessed 2026-09-27
• S2 RFC 8707: Resource Indicators for OAuth 2.0 · standard · accessed 2026-09-27
• S3 MCP Authorization Security Considerations (2026-07-28) · official_documentation · accessed 2026-09-27
• S4 OAuth 2.1 draft, Section 5: Resource Requests · standard · accessed 2026-09-27