Verify MCP Authorization Issuers
Check issuer identity during MCP OAuth discovery and code exchange to prevent authorization-server mix-up.
An MCP client may discover an authorization server before it requests a token. Discovery makes configuration easier, but it also creates a mix-up risk if the client accepts a code from one issuer and redeems it at another. The dated MCP authorization specification calls for issuer information and validation in the authorization flow.
List the expected protected resource, authorization server, redirect URI, and client identity before the first request. The client should follow only the approved discovery chain. HTTPS and a plausible login screen are not enough to establish the issuer. Do not let an untrusted MCP server response replace an already trusted issuer during a code exchange.
Discovery trace
| Step | Expected binding |
|---|---|
| Resource metadata | Identifies the protected MCP resource |
| Authorization server metadata | Names the issuer and endpoints |
| Authorization response | Carries code and any iss value under the advertised metadata rule |
| Token request | Goes to the same validated issuer |
| Token result | Is checked for audience, scopes, and lifetime |
Before redirect, record the issuer from validated authorization-server metadata with the request's PKCE verifier and state. The 2026-07-28 MCP specification gives the exact response rule:
Advertised authorization_response_iss_parameter_supported | Response iss | Required client action |
|---|---|---|
true | Present | Compare exactly with recorded issuer; reject mismatch |
true | Absent | Reject |
false or absent | Present | Compare exactly with recorded issuer; reject mismatch |
false or absent | Absent | Proceed |
Validate state and PKCE under the selected flow. Decode iss before comparison, but do not normalize case, ports, trailing slashes, or percent encoding. Apply the comparison to error responses too, before acting on error text. An absent iss is not always a provider failure; the advertised metadata determines the rule.
Owned-lab mix-up test
Set up two synthetic authorization servers with distinct issuer IDs and signing keys. Start authorization through server A, then inject a response that claims server B. The client must not redeem the code at either endpoint as though nothing changed. Repeat with a matching issuer as the positive control, then test both absent-iss cases against their advertised metadata settings. Capture the redirect destination, metadata used, issuer comparison result, and absence of a token request in the denied case.
Also test metadata refresh. A cached issuer record should not silently become a different authority after a DNS or configuration change. Keep the authorization server allowlist and resource mapping under operator control. A verified issuer only proves the token's origin; the MCP server still needs to check audience and permission for each tool and object.
Know what your agents can reach
Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.
Sources
- MCP Authorization SpecificationAccessed
- MCP Security Best PracticesAccessed