SEP-2468: Recommend Issuer (iss) Claim in MCP Auth Responses#2468
Open
EmLauber wants to merge 1 commit intomodelcontextprotocol:mainfrom
Open
SEP-2468: Recommend Issuer (iss) Claim in MCP Auth Responses#2468EmLauber wants to merge 1 commit intomodelcontextprotocol:mainfrom
EmLauber wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
Proposes requiring the inclusion and validation of an explicit issuer (iss) claim in MCP authorization responses to mitigate authorization mix-up attacks in multi-IdP environments.
localden
changed the title
max-stytch
reviewed
Mar 25, 2026
|
|
||
| ## Abstract | ||
|
|
||
| This SEP proposes requiring the inclusion and validation of an explicit issuer (iss) claim in Model Context Protocol (MCP) authorization responses to mitigate authorization mix‑up attacks. By binding authorization responses to a specific authorization server identity, MCP clients can reliably detect and reject responses originating from an unexpected issuer, improving protocol robustness in multi‑identity provider (IdP) environments. This SEP follows the specifications defined in [RFC9207](https://datatracker.ietf.org/doc/rfc9207/) |
Contributor
There was a problem hiding this comment.
Verbiage nit - 9207 uses parameter instead of claim throughout, since iss is returned as a query parameter (and not as a JWT claim).
|
|
||
| The Model Context Protocol increasingly operates in environments where multiple authorization servers, identity providers, and intermediaries coexist. In such environments, OAuth 2.0 mix‑up attacks become a realistic threat. Mix-up attacks are when an attacker causes a client to associate an authorization response with the wrong authorization server, potentially leading to token leakage or privilege escalation. | ||
|
|
||
| OAuth specifications describes two mitigations for mix‑up attacks: requiring issuer (*iss*) claim or using a unique redirect_uri for each client. A unique redirect_uri is not viable in an MCP environment where dynamic registration is possible. As such, the recommendation is for MCP environments to leverage the issuer mitigation. |
Contributor
There was a problem hiding this comment.
Suggested change
| OAuth specifications describes two mitigations for mix‑up attacks: requiring issuer (*iss*) claim or using a unique redirect_uri for each client. A unique redirect_uri is not viable in an MCP environment where dynamic registration is possible. As such, the recommendation is for MCP environments to leverage the issuer mitigation. | |
| OAuth specifications describes two mitigations for mix‑up attacks: requiring issuer (*iss*) claim or using a unique redirect_uri for each issuer a client interacts with. A unique redirect_uri is not viable in an MCP environment where dynamic registration is possible. As such, the recommendation is for MCP environments to leverage the issuer mitigation. |
| ## Specification | ||
|
|
||
| ###Issuer Claim Requirement | ||
| MCP authorization servers SHOULD include an issuer (*iss*) claim in authorization responses that result in the issuance of access tokens or authorization codes. |
Contributor
There was a problem hiding this comment.
9207 also defines the iss param in error responses. Should we do the same to be consistent with the spec?
Suggested change
| MCP authorization servers SHOULD include an issuer (*iss*) claim in authorization responses that result in the issuance of access tokens or authorization codes. | |
| MCP authorization servers SHOULD include an issuer (*iss*) claim in authorization responses to the client, including error responses. |
| The *iss* claim MUST: | ||
| - Exactly match the issuer identifier advertised via discovery or configuration | ||
| - Its value MUST be a URL that uses the "https" scheme without any query or fragment components. | ||
|
|
Contributor
There was a problem hiding this comment.
WDYT about including the corresponding Authorization Server Metadata update that signals to clients that iss is supported / expected -
Suggested change
| ###Issuer Metadata Requirement | |
| MCP authorization servers that support the `iss` parameter in authorization responses MUST advertise their support by returning `"authorization_response_iss_parameter_supported": true` in their authorization server metadata response as specified in [RFC9207](https://datatracker.ietf.org/doc/html/rfc9207#name-authorization-server-metada). |
(Corresponding language needs to be added to the client validation requirement to check this parameter too)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposes requiring the inclusion and validation of an explicit issuer (iss) claim in MCP authorization responses to mitigate authorization mix-up attacks in multi-IdP environments.
Motivation and Context
How Has This Been Tested?
Tested in OAuth scenarios. Will need additional testing specific to MCP environments before accepting and merging.
Breaking Changes
It is additive fro security. Clients will need to update code to validate the issuer parameter.
Types of changes
Checklist
Additional context
Some auth servers already use the issuer claim and can reference those examples once more details are added.