Register oauth clients with a preferred auth method

[kyle-leonhard]

This PR registers oauth clients with a token_endpoint_auth_method as preferred by the authorization server metadata token_endpoint_auth_methods_supported field, instead of always sending none.

If the authorization server expresses multiple preferences in token_endpoint_auth_methods_supported, the first match from: client_secret_basic, client_secret_post, none is picked. If no preference is expressed, none is picked. Unknown values are ignored.

I don't see any tests around client registration, unfortunately. I could add some with a little help from you experts!

Motivation and Context

Some MCP clients (e.g. vscode) don't currently support any token endpoint auth (microsoft/vscode#257277), but the MCP SDKs do (modelcontextprotocol/typescript-sdk#720). Without this change, one has to guess at when clients actually support token endpoint auth based on other metadata or simply always use None.

How Has This Been Tested?

I tested this locally with my MCP server and authorization server, stepping through the inspector's guided flow to check that client registration matches expectations.

• token_endpoint_auth_methods_supported is empty/absent -> client registration request is sent with client_secret_basic
• token_endpoint_auth_methods_supported=["none"] -> client registration request is sent with none
• token_endpoint_auth_methods_supported=["client_secret_basic", "client_secret_post"] -> client registration request is sent with client_secret_basic
• token_endpoint_auth_methods_supported=["client_secret_post"] -> client registration request is sent with client_secret_post
• token_endpoint_auth_methods_supported=["client_secret_basic", "client_secret_post", "none"] -> client registration request is sent with client_secret_basic

Breaking Changes

No, existing authorization server preferences continue to be respected.

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

[kyle-leonhard]

cc @felixweinberger, @ochafik, @jaredhanson - let me know if you have thoughts and feedback!