Enable additional client conformance scenarios

[halter73]

Summary

• enable six previously failing non-task client conformance scenarios:
  • auth/authorization-server-migration
  • auth/client-credentials-jwt
  • auth/client-credentials-basic
  • auth/enterprise-managed-authorization
  • sep-2322-client-request-state
  • json-schema-ref-no-deref
• keep Basic and private_key_jwt client-credentials acquisition private to the conformance executable rather than expanding the production OAuth API before 2.0
• bind cached OAuth client credentials and refresh tokens to the authorization server that issued them, including safe migration and durable-cache upgrade behavior
• support explicit and deterministic token-endpoint authentication for enterprise identity assertion grants without relying on authorization-server metadata ordering

Fixes #1731.

Related OAuth pull requests

This does not supersede #1615 or #1496:

• Allow setting token endpoint auth method on ClientOAuthOptions (#1612) #1615 adds a direct ClientOAuthOptions.TokenEndpointAuthMethod override for the normal authorization-code/CIMD flow.
• feature: Added configurable token endpoint auth method selection #1496 adds a selector delegate for the same ClientOAuthOptions flow.
• This PR adds TokenEndpointAuthMethod to IdentityAssertionGrantProviderOptions, which is the separate enterprise JWT bearer grant flow. It intentionally does not add either proposed ClientOAuthOptions API.

Those PRs can still address authorization-code client configuration independently. This PR only changes ClientOAuthProvider where required for authorization-server migration and secure cache binding; client-credentials grant implementation remains test-local.

Compatibility

The public API additions are optional properties. Existing enterprise callers continue to prefer client_secret_post when it is supported, regardless of metadata array order, and fall back only when necessary.

Durable cache entries written before TokenContainer.AuthorizationServer existed are not trusted for refresh. They perform a one-time reauthorization so credentials cannot be replayed to an unknown authorization server. Explicit credentials fail closed if a persisted issuer binding later resolves to a different authorization server.

Validation

• all six added conformance scenarios pass on .NET 8, .NET 9, and .NET 10
• focused OAuth cache and identity assertion tests pass on all supported test target frameworks
• dotnet build succeeds with zero warnings
• the complete suite passes when excluding DockerEverythingServerTests.Sampling_Sse_EverythingServer; the unfiltered run fails only because the external pinned Everything server reports Unknown tool: trigger-sampling-request

Generated with GitHub Copilot.

[Copilot]

Pull request overview

This PR expands OAuth-related client behavior and test coverage to enable additional @modelcontextprotocol/conformance client scenarios, while tightening token-cache safety by binding cached credentials/tokens to the issuing authorization server and adding deterministic token-endpoint authentication selection for the enterprise identity assertion grant flow.

Changes:

• Add authorization-server issuer binding to cached OAuth client credentials/tokens and enforce safe migration/refresh behavior in ClientOAuthProvider.
• Add IdentityAssertionGrantProviderOptions.TokenEndpointAuthMethod and implement deterministic token endpoint authentication method selection (preferring client_secret_post when supported).
• Enable and support additional client conformance scenarios via the conformance test runner, new OAuth helpers, and expanded test coverage.

Show a summary per file

File	Description
tests/ModelContextProtocol.Tests/IdentityAssertionGrantTests.cs	Adds assertions and new tests for token endpoint auth method behavior in the identity assertion grant flow.
tests/ModelContextProtocol.ConformanceClient/Program.cs	Extends conformance scenario handling, including special-casing OAuth scenarios and pinning protocol version for select tests.
tests/ModelContextProtocol.ConformanceClient/ConformanceOAuthHelpers.cs	Introduces conformance-only helpers for discovery and acquiring tokens for client-credentials and enterprise flows.
tests/ModelContextProtocol.AspNetCore.Tests/OAuth/TokenCacheTests.cs	Adds tests ensuring cached tokens/credentials are not refreshed across different authorization servers and validates upgrade/migration behavior.
tests/ModelContextProtocol.AspNetCore.Tests/ClientConformanceTests.cs	Enables additional previously-disabled conformance scenarios.
src/ModelContextProtocol.Core/Authentication/TokenContainer.cs	Adds AuthorizationServer to bind cached credentials/tokens to the issuing authorization server.
src/ModelContextProtocol.Core/Authentication/IdentityAssertionGrantProviderOptions.cs	Adds TokenEndpointAuthMethod option for enterprise identity assertion grant flow configuration.
src/ModelContextProtocol.Core/Authentication/IdentityAssertionGrantProvider.cs	Validates token endpoint auth method input and selects an auth method deterministically based on metadata/options.
src/ModelContextProtocol.Core/Authentication/IdentityAssertionGrant.cs	Implements client_secret_basic vs client_secret_post vs none behavior for JWT bearer token exchange requests.
src/ModelContextProtocol.Core/Authentication/ExchangeJwtBearerGrantOptions.cs	Adds internal TokenEndpointAuthMethod plumbing for JWT bearer grant exchange.
src/ModelContextProtocol.Core/Authentication/ClientOAuthProvider.cs	Binds restored/stored cached credentials to the selected authorization server and gates refresh/restore accordingly.

Review details

• Files reviewed: 11/11 changed files
• Comments generated: 1
• Review effort level: Low

[PranavSenthilnathan]

TokenEndpointAuthMethod should reject secret-based methods when ClientSecret is null or empty. As written, client_secret_basic sends an empty password, while client_secret_post silently omits client_secret, so an invalid option combination is accepted and only fails later at the authorization server with a misleading error.

Could we validate this in IdentityAssertionGrantProvider's constructor and add coverage for both methods? Since this PR introduces the public option, I think the invalid combinations should fail deterministically before the API ships.

Generated with GitHub Copilot.