Researched guidance: How should an MCP connector diagnose invalid_target separately from invalid_scope?

Summary

Diagnose the failure by locating it in the OAuth exchange versus the protected MCP request, then classify the faulty dimension: `invalid_target` is for the RFC 8707 resource/target (including a resource-plus-scope combination the authorization server rejects), `invalid_scope` is for the requested scope value or grant, and `insufficient_scope` is the protected-resource runtime signal when a valid token lacks permission.

Candidate action

1. Capture the exact failing hop, HTTP status, endpoint, `resource`, `scope`, grant type, authorization-server issuer, MCP server canonical URI, and full error fields without logging token values. 2. If the authorization or token endpoint returns `invalid_target`, validate that the MCP client sent RFC 8707 `resource` in both requests, that it is an absolute URI without a fragment, that it is the canonical MCP server URI, and that the authorization server recognizes/permits it; compare the resource and scope together because RFC 8707 also allows `invalid_target` for an invalid resource-and-scope combination. 3. If the authorization or token endpoint returns `invalid_scope`, keep the resource diagnosis separate and validate the scope syntax, whether each scope is known for that authorization server/resource, and whether the request exceeds the resource owner's granted scope; on refresh, do not request a scope outside the original grant. 4. If the MCP protected-resource request returns 401, investigate missing, expired, malformed, or wrong-audience tokens and the `WWW-Authenticate` challenge; MCP requires audience validation and 401 for invalid or expired tokens. If it returns 403 with a valid audience, investigate authorization for the operation and classify a missing privilege as RFC 6750 `insufficient_scope`, using the advertised scope challenge for step-up or correction. 5. Log the classification and the normalized resource/scope comparison so a client bug (wrong or missing target) is not conflated with an authorization policy decision (scope) or a runtime permission failure (insufficient scope).

Applicability

• HTTP-based MCP clients, authorization servers, and MCP protected resources implementing the MCP authorization specification.
• OAuth authorization-code and token exchanges that use RFC 8707 Resource Indicators, including refresh-token requests.
• Troubleshooting token-endpoint errors, authorization-endpoint errors, wrong-audience tokens, and runtime permission failures.

Key findings

• MCP clients must send the RFC 8707 resource parameter in both authorization and token requests, using the canonical MCP server URI; MCP servers must validate that tokens are intended for them, and invalid or expired tokens receive HTTP 401. (S1)
• RFC 8707 defines invalid_target for a resource that is invalid, missing, unknown, or malformed, and also permits it for an invalid combination of resource and scope; the resource value must be an absolute URI without a fragment. (S2)
• RFC 6749 defines invalid_scope for a requested scope that is invalid, unknown, malformed, or, at the token endpoint, exceeds the scope granted by the resource owner; token-endpoint errors use HTTP 400. (S3)
• RFC 6750 defines insufficient_scope at the protected resource: the token is usable for authentication but lacks the privileges required, so the resource server should return HTTP 403 and may advertise the required scope in WWW-Authenticate. (S4)

Known limitations

• MCP's authorization page states the required resource parameter, audience validation, and broad 401/403 mapping but does not define a complete invalid_target-versus-invalid_scope decision tree; the finer classification comes from RFC 8707, RFC 6749, and RFC 6750.
• RFC 8707 permits invalid_target for an invalid combination of resource and scope, so an authorization server's local policy can make a mixed failure ambiguous; retain the raw response and error_description rather than inferring a single field from the code alone.
• The specifications do not reveal whether a particular authorization server recognizes an MCP URI, how it maps resource URIs to audiences, or which scopes are enabled for a tenant; those are deployment-policy questions.
• Documentation research only: no live OAuth exchange, token validation, or MCP request was executed and no independent reproduction was performed.

Negative results

• Do not use `invalid_scope` as a synonym for a missing, malformed, unknown, or non-canonical MCP resource; that is the target/resource branch unless the server explicitly reports a mixed resource-and-scope rejection.
• Do not treat a runtime 403 as proof that the token endpoint issued `invalid_scope`; RFC 6750 uses `insufficient_scope` for a valid bearer token that lacks the privileges needed by the protected resource.
• Do not treat a successful token response as proof that the token is usable at the MCP server; MCP still requires the server to validate intended audience and reject wrong-audience tokens.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• The sources establish protocol meanings and recommended diagnostic sequencing, not a passing result from a particular MCP deployment.

What remains unknown

• Which OAuth endpoint or MCP request produced the observed error, its HTTP status, and the exact error_description or WWW-Authenticate challenge.
• The canonical MCP server URI, resource value sent on each OAuth leg, issuer policy, effective scope grant, and token audience in the affected deployment.
• Whether the authorization server applies a local resource/scope policy that intentionally reports a mixed failure as invalid_target.

Evidence status

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

Sources

• S1 Authorization - Model Context Protocol (2025-06-18) · official_documentation · accessed 2026-09-21
• S2 RFC 8707: Resource Indicators for OAuth 2.0 · standard · accessed 2026-09-21
• S3 RFC 6749: The OAuth 2.0 Authorization Framework · standard · accessed 2026-09-21
• S4 RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage · standard · accessed 2026-09-21