[RobotechUSA]

Summary

The OAuth client currently selects the first token endpoint authentication method advertised by the authorization server. That can fail when a server exposes multiple supported methods and the client needs to prefer a specific method based on client type or available credentials.

This change adds TokenEndpointAuthMethodSelector to ClientOAuthOptions and uses it in ClientOAuthProvider when resolving the token endpoint authentication method. Existing behavior is preserved by defaulting to the first advertised method when no selector is provided.

Motivation and Context

Some authorization servers advertise multiple token endpoint authentication methods. In those cases, always choosing the first advertised method is not flexible enough for clients that need to prefer a different supported method.

This change allows callers to control that selection without changing the default behavior for existing consumers.

How Has This Been Tested?

Validated in a downstream application that requires selecting a specific token endpoint authentication method.

Breaking Changes

This is a non-breaking change. Existing behavior is preserved when TokenEndpointAuthMethodSelector is not configured.

Types of changes

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

Checklist

• I have read the MCP Documentation
• 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

N/A

[halter73]

#1615 proposes an explicit TokenEndpointAuthMethod setting, which I’d prefer over adding a selector callback. Would that cover your downstream application, or does it need to choose based on discovery at runtime? One distinction is that this selector leaves DCR unchanged, while #1615 also uses the configured method in registration requests. I’d like to understand whether that matters for your scenario before closing this in favor of #1615. Thanks!

[RobotechUSA]

#1615 proposes an explicit TokenEndpointAuthMethod setting, which I’d prefer over adding a selector callback. Would that cover your downstream application, or does it need to choose based on discovery at runtime? One distinction is that this selector leaves DCR unchanged, while #1615 also uses the configured method in registration requests. I’d like to understand whether that matters for your scenario before closing this in favor of #1615. Thanks!

Thanks for taking a look and for laying out the comparison.

The idea behind this PR was to keep the SDK unopinionated. Instead of the SDK picking the token endpoint auth method, the selector hands that decision, along with any validation of what discovery returns, to the application. I also wanted to keep the change to the SDK as small as possible while still covering our scenario.

That said, the explicit TokenEndpointAuthMethod setting in #1615 can work for our needs. We don't need to pick the method at runtime based on discovery, and having the configured method also apply to DCR requests is fine for us.

I understand the preference for the explicit setting, and I'm ok with you closing this in favor of #1615.

Thanks again for considering my effort.