Validate the RFC 9207 iss parameter and bind MCP client credentials to the issuing authorization server

Documented steps

1. Read https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization. This revision adds RFC 9207 to the required standards set (SEP-2468) and tightens credential-to-issuer binding (SEP-2352).
2. Discover the authorization server through OAuth 2.0 Protected Resource Metadata (RFC 9728). MCP servers MUST implement it and clients MUST use it for AS discovery.
3. On a 401, read the WWW-Authenticate challenge, e.g. 'Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"'. Treat the challenge scopes as authoritative and do not assume any relationship to scopes_supported.
4. Fetch and validate the AS metadata via RFC 8414 or OpenID Connect Discovery 1.0. Clients MUST support both mechanisms; an MCP authorization server MUST provide at least one.
5. RECORD the 'issuer' value from the validated AS metadata alongside the same per-request record that holds your PKCE code_verifier and state.
6. Check whether the AS advertises 'authorization_response_iss_parameter_supported'. An AS that includes iss MUST advertise true.
7. Apply RFC 9207 section 2.4 validation BEFORE transmitting the authorization code to any token endpoint: if supported is true and iss is present, compare it to the recorded issuer; if supported is true and iss is ABSENT, REJECT the response; if supported is false or absent and iss is present, compare it to the recorded issuer; if both are absent, proceed.
8. Compare with simple string comparison per RFC 3986 section 6.2.1. After form-urlencoded decoding, do NOT case-fold the scheme or host, elide default ports, adjust trailing slashes, or normalize percent-encoding before comparing.
9. On mismatch, MUST NOT act on or display error, error_description or error_uri. This applies to error responses too.
10. Include the RFC 8707 'resource' parameter in BOTH the authorization request and the token request, set to the canonical URI of the MCP server, and send it whether or not the AS supports it.
11. Use the most specific canonical URI available; lowercase scheme and host is canonical though implementations SHOULD accept uppercase. Omit a trailing slash unless it is semantically significant. 'mcp.example.com' (no scheme) and a URI with a fragment are invalid.
12. Send the token as 'Authorization: Bearer <token>' on every HTTP request, and MUST NOT put it in the URI query string.
13. Server side: validate tokens per OAuth 2.1 section 5.2 AND validate that the token was issued specifically for you as the intended audience per RFC 8707 section 2. Return 401 for invalid or expired tokens, 403 for insufficient scope, 400 for a malformed authorization request.
14. Key persisted client credentials by the AS issuer identifier, MUST NOT reuse them with a different AS, and MUST re-register when the AS changes (detected via updated protected resource metadata).
15. Handle refresh tokens carefully: keep them confidential in transit and storage, SHOULD include refresh_token in grant_types, MAY request offline_access only if the AS advertises it, and MUST NOT assume a refresh token will be issued.
16. Verify: simulate an AS that advertises iss support but omits iss, and confirm your client rejects the response rather than redeeming the code.