MCP-AUT-005

AS advertises authorization_response_iss_parameter_supported: true

“MCP authorization servers SHOULD include the iss parameter in authorization responses... Authorization servers that include the iss parameter MUST advertise this by setting authorization_response_iss_parameter_supported to true.” — spec anchor

How to fix this

Set `authorization_response_iss_parameter_supported: true` in your authorization server's metadata once it reliably includes `iss` in every authorization response, success or error (RFC 9207 §2.3). A client that sees the flag set but `iss` missing is required to reject the response outright.

Example: failing and passing

The authorization server metadata omits authorization_response_iss_parameter_supported, which RFC 9207 defaults to false.

Violates MCP-AUT-005 · JSON

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"]
}

The metadata sets authorization_response_iss_parameter_supported to true, telling clients every authorization response carries iss.

Complies with MCP-AUT-005 · JSON

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"],
  "authorization_response_iss_parameter_supported": true
}

How the validator checks this

Probe P8.3, against a streamable-http server on the modern protocol. What it reports:

pass: Every authorization server advertises authorization_response_iss_parameter_supported: true
warn: Does not advertise authorization_response_iss_parameter_supported: …. Without it a client cannot confirm which authorization server answered — the RFC 9207 mix-up defence.

Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.

This rule is checked deterministically: a fail here is a certain violation, not an inference.

Checked in the same request as MCP-AUT-004, MCP-AUT-010, MCP-AUT-011.

Check your own server against MCP-AUT-005

Probe P8.3 checks MCP-AUT-005 in the same request as 3 other rules, so one run shows your server's result for this rule next to the rest. Validate a server or read how the validator works.

Background on this topic: how to add OAuth to an MCP server.

Other Authorization rules

MCP-AUT-001Unauthenticated request returns 401 with WWW-Authenticate resource_metadata
MCP-AUT-002RFC 9728 Protected Resource Metadata is served and valid
MCP-AUT-003PRM resource equals the canonical server URI
MCP-AUT-004Each listed authorization server exposes RFC 8414 or OIDC discovery metadata
MCP-AUT-006WWW-Authenticate includes a scope parameter
MCP-AUT-007Insufficient scope returns 403 with error="insufficient_scope"
MCP-AUT-008Tokens with a foreign audience are rejected
MCP-AUT-009offline_access absent from scopes_supported / challenge scope
MCP-AUT-010AS advertises S256 in code_challenge_methods_supported
MCP-AUT-011AS supports Client ID Metadata Documents, not DCR alone