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

[mikekistler]

Is your feature request related to a problem? Please describe.

Implement support for SEP-2468, which is planned for inclusion in the 2026-06-30 version of the MCP spec.

Describe the solution you'd like

Compliance with the 2026-06-30 version of the MCP spec within two weeks of its release.

[mikekistler]

Analysis of SEP-2468 Changes Required

What SEP-2468 Requires

SEP-2468 implements RFC 9207 to mitigate OAuth mix-up attacks. The changes fall into two categories:

Server-side (SHOULD): Authorization servers SHOULD include iss in authorization responses and advertise authorization_response_iss_parameter_supported: true in metadata.

Client-side (MUST): Clients MUST validate the iss parameter per this decision table:

authorization_response_iss_parameter_supported	iss in response	Client action
true	present	Compare to recorded issuer (exact string match, no normalization)
true	absent	Reject the response
false or absent	present	Compare to recorded issuer (exact string match)
false or absent	absent	Proceed normally

Additionally, clients MUST validate fetched metadata documents per RFC 8414 §3.3: the issuer value in the document MUST match the issuer identifier used to construct the well-known URL.

---

Changes Needed in the C# SDK

1. Add AuthorizationResponseIssParameterSupported to AuthorizationServerMetadata

   • New bool property with [JsonPropertyName("authorization_response_iss_parameter_supported")]

2. Change AuthorizationRedirectDelegate signature

   • Currently returns Task<string?> (just the authorization code). It needs to also return the iss query parameter from the redirect URI.
   • Introduce a new AuthorizationResult record with Code and Iss properties and change the delegate return type.

3. Add issuer validation in InitiateAuthorizationCodeFlowAsync

   • After receiving the callback result (code + iss), validate iss against the recorded authServerMetadata.Issuer using the decision table above.
   • Comparison must be exact simple string comparison — no scheme/host case folding, no port elision, no trailing-slash normalization.

4. Add metadata issuer validation in GetAuthServerMetadataAsync

   • After deserializing metadata, verify that metadata.Issuer matches the issuer URI used to construct the well-known URL (per RFC 8414 §3.3).

---

Comparison with Other SDK Implementations

Aspect	Go SDK (#859, merged)	TypeScript SDK (#1957, draft)	Proposed C# SDK
Result type	Added Iss field to AuthorizationResult struct	finishAuth(code, iss?) optional param	New AuthorizationResult record, changed delegate
Validation location	validateIssuerResponse() standalone func	Inside finishAuth	Inside InitiateAuthorizationCodeFlowAsync
Row 3 behavior (not advertised + iss present)	Rejects (stricter than spec)	Compares (per spec)	Should compare (follow spec)
Metadata issuer validation (RFC 8414 §3.3)	Not visible in diff	Not visible in diff	Add in GetAuthServerMetadataAsync

Key divergence: The Go SDK rejects when iss is present but not advertised (row 3), which is stricter than the SEP spec. The SEP explicitly says to compare in this case, reasoning that "authorization servers often begin emitting iss before their metadata is updated, and discarding in that window would reject legitimate flows without security benefit." The C# SDK should follow the spec and compare rather than reject.

---

Breaking Change Considerations

The AuthorizationRedirectDelegate is a public delegate — changing its return type is a source-breaking change. The SEP's backward-compatibility section anticipates this: "SDKs are expected to widen callback signatures additively (e.g., an optional iss argument) so existing call sites continue to compile."

Plan: Introduce a new AuthorizationResult class and change the delegate return type. This is breaking but clean and aligns with how the Go SDK handles it.