What is RFC 9207 iss validation in MCP OAuth?

The short answer

HTTP/1.1 302 Found
Location: https://client.example.com/callback
            ?code=SplxlOBeZQQYbYS6WxSbIA
            &state=af0ifjsldkj
            &iss=https%3A%2F%2Fauth.example.com   ← RFC 9207

// The client MUST compare that iss against the issuer it
// expected for this authorization request, and refuse to
// redeem the code if they differ.

• The authorization server sends iss and advertises that it does.
• The client compares it and rejects a mismatch.
• Your MCP server never sees the authorization response at all.

The attack it closes

Mix-up only threatens a client that talks to more than one authorization server — which, for an MCP client connecting to arbitrary servers, is the normal case rather than an edge case.

1. Client starts a login. It intends to authenticate at
   honest-as.example, but an attacker influences the choice
   and it actually starts the flow at attacker-as.example.

2. attacker-as.example redirects back to the client's real
   callback with a code.

3. The callback carries: code, state. Nothing else.
   The client knows a code arrived. It does NOT know which
   authorization server minted it.

4. The client redeems that code at honest-as.example —
   or hands the attacker a code meant for the honest server.

   The redirect looked correct. state matched. The only
   missing fact was "who answered".

iss supplies exactly that missing fact, and nothing else. It is a small parameter for a narrow, real problem — which is why it is worth understanding once rather than treating as generic OAuth boilerplate.

Whose job is it? (the part most write-ups skip)

Concretely, the three roles split like this:

That third row is the only lever you have, and it is a real one: your Protected Resource Metadata names the authorization servers clients should use. Naming one that does not support iss is a choice you are making on behalf of every client that connects to you.

What MCP 2026-07-28 actually requires

Read the two halves carefully, because they have different strengths. Sending the parameter is SHOULD. Advertising it, if you send it, is MUST — an authorization server that emits iss without declaring support is worse than one that does neither, because a client cannot rely on a parameter it was not told to expect.

Checking whether your authorization server supports it

# RFC 8414 (OAuth 2.0 Authorization Server Metadata)
curl -s https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '.authorization_response_iss_parameter_supported'

# OpenID Connect Discovery 1.0
curl -s https://auth.example.com/.well-known/openid-configuration \
  | jq '.authorization_response_iss_parameter_supported'

# true   → supported and advertised
# false  → explicitly not supported
# null   → the field is absent, which means the same as false

An absent field and false are equivalent for your purposes. The spec requires servers that send iss to advertise it, so silence is a claim: this server does not send it.

Where this sits in the rest of the auth chain

iss validation is one link. The checks around it are the ones your MCP server can satisfy directly, and they are what makes discovering your authorization server possible in the first place:

The chain runs: an unauthenticated request gets a 401 whose WWW-Authenticate header points at your Protected Resource Metadata; that document names your authorization servers; each of those exposes metadata; and that metadata is where authorization_response_iss_parameter_supported lives. Break any earlier link and the client never gets far enough to care about iss.

PKCE with S256 sits alongside iss as the other defence against code interception — different attack, same stage of the flow, and also advertised through authorization server metadata rather than implemented by you.

The 11 authorization rules we check

All eleven carry verbatim spec sentences. Note that several describe the authorization server's behaviour: we reach them by following your Protected Resource Metadata outward, and report the result on your server's report because your metadata is what pointed us there.

Frequently asked

Related