SEP-2468: Recommend Issuer (iss) Claim in MCP Auth Responses by EmLauber · Pull Request #2468 · modelcontextprotocol/modelcontextprotocol

EmLauber · 2026-03-25T22:49:52Z

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

Problem: MCP operates in multi-IdP environments where mix-up attacks are possible
Solution: Require issuer claim validation in clients to bind responses to correct auth server
Follows: RFC 9207 specifications for OAuth security

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

Bug fix (non-breaking change which fixes an issue)
[ x] New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
[x ] Documentation update

Checklist

[ x] I have read the MCP Documentation
[ x] My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

Some auth servers already use the issuer claim and can reference those examples once more details are added.

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.

max-stytch · 2026-03-25T23:16:33Z

+
+## 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/)


Verbiage nit - 9207 uses parameter instead of claim throughout, since iss is returned as a query parameter (and not as a JWT claim).

max-stytch · 2026-03-25T23:32:45Z

+
+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.


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.

max-stytch · 2026-03-25T23:35:29Z

+## 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.


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.

max-stytch · 2026-03-25T23:40:26Z

+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.
+


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)

aaronpk · 2026-03-30T15:15:35Z

I don't think we should bring in any new dependencies in this PR other than the iss defined in RFC9207, especially not something defined in a not-yet-adopted individual draft.

SamMorrowDrums

Looks like a great addition. Added a couple of nits but should also add a link to the best practices documentation: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

Specifically the confused deputy section. Then you can also update the guidance based on this being merged.

SamMorrowDrums · 2026-04-01T14:20:44Z

+- 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.
+
+###Client Validation Requirements


Suggested change

###Client Validation Requirements

### Client Validation Requirements

Nit titles need spaces

SamMorrowDrums · 2026-04-01T14:21:27Z

+
+## Specification
+
+###Issuer Claim Requirement


Suggested change

###Issuer Claim Requirement

### Issuer Claim Requirement

Nit titles need spaces

pcarleton · 2026-04-03T16:58:01Z

+
+###Client Validation Requirements
+MCP clients MUST validate the *iss* claim in authorization responses by:
+- Determining the expected issuer for the authorization request


i might tweak this to be more clear that the client needs to keep track of the issuer parameter before redirect (regardleess of metadata indicaitng support). As in if you get back iss i think you want to be able to validate it, and if you haven't stored it, you're out of luck

Adds 5 draft conformance scenarios testing RFC 9207 issuer parameter validation in OAuth authorization responses: - auth/iss-supported: server advertises support and sends correct iss - auth/iss-not-advertised: server omits iss parameter entirely - auth/iss-supported-missing: client must reject missing iss when required - auth/iss-wrong-issuer: client must reject mismatched iss value - auth/iss-unexpected: client must reject iss when not advertised Also adds auth-test-iss-validation.ts, a reference client that correctly validates iss per RFC 9207, and negative tests confirming the standard client fails all three rejection scenarios. TODO: Update RFC_9207_ISS_PARAMETER spec reference once SEP-2468 (modelcontextprotocol/modelcontextprotocol#2468) is merged.

sep-automation-bot · 2026-04-13T10:29:25Z

State Transition: proposal → draft

This SEP has been transitioned from proposal to draft.

@pcarleton has been assigned as the sponsor for this SEP.

This is an automated message from the SEP lifecycle bot.

Add SEP: Recommend Issuer (iss) Claim in MCP Auth Responses

025222f

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 ~~Add SEP: Recommend Issuer (iss) Claim in MCP Auth Responses~~ SEP-2468: Recommend Issuer (iss) Claim in MCP Auth Responses Mar 25, 2026

localden added auth security proposal SEP proposal without a sponsor. SEP labels Mar 25, 2026

github-project-automation bot added this to SEP Review Pipeline Mar 25, 2026

max-stytch reviewed Mar 25, 2026

View reviewed changes

max-stytch mentioned this pull request Mar 26, 2026

auth: issuer mix-up mitigation modelcontextprotocol/go-sdk#859

Open

This comment was marked as spam.

Sign in to view

SamMorrowDrums reviewed Apr 1, 2026

View reviewed changes

pcarleton reviewed Apr 3, 2026

View reviewed changes

localden linked an issue Apr 8, 2026 that may be closed by this pull request

Make RFC 9207 issuer validation (OAuth mixup attack prevention) mandatory #1721

Open

localden mentioned this pull request Apr 8, 2026

The authorization spec is unclear when multiple Authorization servers are involved #1349

Closed

max-stytch mentioned this pull request Apr 9, 2026

feat: add conformance tests for iss parameter (SEP-2468) modelcontextprotocol/conformance#220

Open

9 tasks

pcarleton self-assigned this Apr 13, 2026

sep-automation-bot bot removed the proposal SEP proposal without a sponsor. label Apr 13, 2026

sep-automation-bot bot added the draft SEP proposal with a sponsor. label Apr 13, 2026

pcarleton added this to the 2026-06-30-RC milestone Apr 13, 2026

dsp-ant added the roadmap/security Roadmap (horizon): Security & Authorization label Apr 15, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SEP-2468: Recommend Issuer (iss) Claim in MCP Auth Responses#2468

SEP-2468: Recommend Issuer (iss) Claim in MCP Auth Responses#2468
EmLauber wants to merge 1 commit intomodelcontextprotocol:mainfrom
EmLauber:sep-issuer-claim-auth

EmLauber commented Mar 25, 2026

Uh oh!

max-stytch Mar 25, 2026

Uh oh!

max-stytch Mar 25, 2026

Uh oh!

max-stytch Mar 25, 2026

Uh oh!

max-stytch Mar 25, 2026

Uh oh!

This comment was marked as spam.

aaronpk commented Mar 30, 2026

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

SamMorrowDrums left a comment

Uh oh!

SamMorrowDrums Apr 1, 2026

Uh oh!

SamMorrowDrums Apr 1, 2026

Uh oh!

pcarleton Apr 3, 2026

Uh oh!

sep-automation-bot bot commented Apr 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants


		## 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/)


		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.

	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.



	###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).

	###Client Validation Requirements
	### Client Validation Requirements

Conversation

EmLauber commented Mar 25, 2026

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

max-stytch Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

max-stytch Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

max-stytch Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

max-stytch Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

This comment was marked as spam.

aaronpk commented Mar 30, 2026

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

SamMorrowDrums left a comment

Choose a reason for hiding this comment

Uh oh!

SamMorrowDrums Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

SamMorrowDrums Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

pcarleton Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

sep-automation-bot bot commented Apr 13, 2026

State Transition: proposal → draft

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants