Implement RFC 9207 issuer validation in ClientOAuthProvider

[mikekistler]

Summary

Implements SEP-2468 and RFC 9207 issuer (iss) parameter validation in the OAuth authorization flow.

Closes #1571

Changes

• AuthorizationCallbackContext: New context containing the authorization and redirect URIs.
• AuthorizationResult: New result containing the authorization code and optional issuer from the authorization response.
• ClientOAuthOptions: Adds the issuer-aware AuthorizationCallbackHandler. The existing AuthorizationRedirectDelegate remains available as an obsolete compatibility API under diagnostic MCP9007.
• ClientOAuthProvider: Validates authorization response issuers per RFC 9207 and authorization server metadata issuers per RFC 8414 Section 3.3.
• AuthorizationServerMetadata: Adds the Issuer and AuthorizationResponseIssParameterSupported properties.
• Default manual authorization flow: Accepts the full redirect URL and extracts both code and iss.
• Conformance client and tests: Updated for issuer-aware authorization responses and legacy callback compatibility.

Migration

• Existing AuthorizationRedirectDelegate implementations retain their original signature and continue to work, but now produce warning MCP9007. This compatibility path cannot return iss, so RFC 9207 authorization-response issuer validation is skipped when it is used. Migrate to AuthorizationCallbackHandler for issuer-aware authorization.
• AuthorizationCallbackHandler receives an AuthorizationCallbackContext and returns an AuthorizationResult containing the code and, when present, iss query parameters from the redirect.
• AuthorizationCallbackHandler and AuthorizationRedirectDelegate cannot both be configured. Doing so throws an ArgumentException.
• The built-in manual handler now prompts for the full absolute redirect URL instead of only the authorization code. Pasting only the code produces an explicit invalid-URL error. Paste the complete URL from the browser address bar so the SDK can extract and validate iss.

RFC 9207 Behavior

1. When the authorization server advertises RFC 9207 support, the authorization response must include an iss value that exactly matches the expected issuer.
2. When the server does not advertise support but returns iss, the client still validates it.
3. Authorization server metadata issuer is validated exactly against the expected URI per RFC 8414 Section 3.3. The 2025-03-26 compatibility path skips this metadata comparison because its discovery URI is derived from the MCP server origin rather than Protected Resource Metadata.
4. If the server neither advertises support nor returns iss, RFC 9207 cannot protect the flow and authorization proceeds normally.
5. Validation failures reject the authorization response with a descriptive error.

[halter73]

@tarekgh @PranavSenthilnathan I updated this to make the breaking API change I suggested in my earlier comment. Let me know what you think.

[tarekgh]

@tarekgh @PranavSenthilnathan I updated this to make the breaking API change I suggested in my earlier comment. Let me know what you think.

@halter73 I have left a few comments, but in general LGTM.

[tarekgh]

@halter73 could you please resolve the conflict to the see the CI results?

[halter73]

I addressed the PR feedback, but wait a minute before rereviewing. I'm going to add the AuthorizationRedirectDelegate back temporarily as an obsolete API for back-compat purposes.

[halter73]

This should be ready for final review. I added back the old delegate as an obsolete API for better back compat.

[tarekgh]

LGTM, Thanks!

[jeffhandley]

Release audit: labeled breaking-change because AuthorizationRedirectDelegate is newly obsolete with MCP9007, which breaks consumers that treat warnings as errors. Migrate callback implementations to AuthorizationCallbackHandler and AuthorizationResult; the manual flow now also requires the complete redirect URL.