Request: make resource parameter OPTIONAL (RFC 8707-aligned) #1599

The MCP authorization spec currently requires clients to always send a resource parameter:

“MCP clients MUST implement Resource Indicators (RFC 8707)… resource MUST be included in both authorization requests and token requests… and MUST identify the MCP server.” ([MCP Authorization Section 2.5.1]1)

This contradicts two stated goals of the spec—interoperability and simplicity—and it’s not consistent with RFC 8707. RFC 8707 explicitly makes resource optional:

“In requests to the authorization server, a client MAY indicate the protected resource… by including the resource parameter.” ([RFC 8707 Section 2-1]2)

And §2.1 is explicit that omitting resource is permitted; servers MAY still process the request (or MAY require it and fail with invalid_target):

“If the client omits the resource parameter… the authorization server MAY process the request with no specific resource… Alternatively, the authorization server MAY require clients to specify the resource(s)… and MAY fail requests that omit the parameter with an invalid_target error.” ([RFC 8707 Section 2.1-3]3)

The current MCP language therefore turns a MAY into a MUST, which (a) diverges from RFC 8707’s intent and (b) breaks interoperability with major IdPs that don’t accept resource at /authorize.

Real-world breakage

• Microsoft Entra ID (v2) rejects resource at /authorize and is scope-centric; the supported pattern is scope={resource}/.default (functional equivalent of v1 resource=...). Developers routinely hit AADSTS901002: The 'resource' request parameter is not supported. ([Microsoft Learn]4)
  (See the MCP Inspector issue demonstrating this failure mode.) ([GitHub]5)

• OIDC Core centers consent/audience around scope, not resource, and never requires resource. ([OpenID Foundation]6)

Also: even when a client does send resource, RFC 6749 says servers MUST ignore unrecognized request parameters—so relying on universal enforcement is wishful thinking. Audience binding must be validated at the resource server regardless. ([RFC 6749 Section 4.1.2]7)

Standards compliance & discovery constraints

• The MCP spec’s own standards-compliance goals emphasize interoperability and simplicity. Mandating resource across the board undermines both by forcing non-portable client behavior. ([MCP Authorization Section 1.3]1)

• RFC 8707's resource parameter is an optional extension. Treating an RFC MAY as a protocol-level MUST is not RFC-aligned. ([IETF Datatracker]3)

• No discovery signal exists to tell clients whether an AS supports or requires resource. Neither OAuth 2.0 AS Metadata (RFC 8414) nor OIDC Discovery define a flag for RFC 8707 support. Providers legitimately differ, and clients can’t learn this from .well-known. ([RFC 8414]11, [OIDC Discovery 1.0]12)

Given that reality, the spec should not require resource unconditionally.

Proposed spec changes (minimal, standards-aligned)

1. Relax the requirement.
   Change “resource MUST be included in authorization and token requests” to:

   “MCP clients SHOULD use RFC 8707 Resource Indicators. When the AS supports RFC 8707 for the relevant endpoint(s), clients SHOULD send resource. When the AS rejects or ignores resource, clients MUST fall back to a scope-based audience signal.”

   This honors RFC 8707’s optional semantics and keeps the security goal.

2. Define an interoperable fallback.
   Add explicit guidance for non-8707 IdPs (e.g., Microsoft Entra v2):

   • Authorization request: omit resource; request scopes for a single API.
   • Token request (app-only / .default cases): if the AS is Entra v2, use scope={resource}/.default. (Microsoft’s documented bridge from v1 resource to v2 scopes.) ([Microsoft Learn]8)

3. Discovery hint (non-normative).
   Because there’s no metadata flag for RFC 8707 support:

   • Prefer explicit configuration (or PRM/server config) of ASs known to accept resource. (MCP already leans on Protected Resource Metadata, RFC 9728.) ([RFC Editor]9)
   • If unknown, either (a) default to scope-only for a single API, or (b) try resource once; on invalid_target or known provider-specific errors (e.g., AADSTS901002), retry without resource and continue scope-based. ([IETF Datatracker]3)

4. Keep audience checks a MUST.
   Regardless of request shape, MCP servers MUST verify that received tokens are audience-restricted to themselves (e.g., via aud) and MUST reject tokens not issued for them. This matches RFC 8707’s security rationale. ([IETF Datatracker]3)

Why this is the right trade-off

• Standards coherence: Honors RFC 8707’s optional model instead of redefining it.
• Interoperability: Works out-of-the-box with Entra v2 (and other scope-centric IdPs) and with providers that implement Resource Indicators. ([Microsoft Learn]4)
• Simplicity: No new discovery heuristics; one clean fallback path.
• Security preserved: Audience binding enforced where it matters (resource server), and clients use resource where it’s actually supported. ([IETF Datatracker]3)

References: RFC 8707 (Resource Indicators), RFC 6749 (OAuth 2.0), RFC 8414 (AS Metadata), OIDC Core & Discovery, Microsoft Entra docs on scopes/.default, MCP Inspector issue, MCP Authorization spec, RFC 9728 (Protected Resource Metadata), IETF Datatracker.