fix: Prefer the token_endpoint_auth_method response from DCR registration

[chipgpt]

Updates the OAuth authorization flow to prefer to use the token_endpoint_auth_method result from the Dynamic Client Registration endpoint, if provided.

#951

Motivation and Context

When using dynamic client registration, the registration endpoint may return the token_endpoint_auth_method value to be used when exchanging tokens for access tokens. The current oauth implementation ignores this field and only uses the methods from the oauth authorization server metadata.

How Has This Been Tested?

This has not been tested in a real application.

Breaking Changes

No breaking changes.

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

Previous PR #982 is no longer showing changes after rebase for some reason and was automatically closed, reopening new PR

[pcarleton]

this type signature change worries me a bit. The OAuthClientInformation is the response from the DCR endpoint, listed here:
https://datatracker.ietf.org/doc/html/rfc7591#section-3.2.1

All the fields are optional except for redirect_uris (which is what I think is what required a bunch of changes in tests).

this means this change will be backwards incompatible for implementations of the provider that directly return the DCR response rather than the full metadata.

saveClientInformation takes the full information type, so this might be a non issue.

to land this, we'll either want to:

• check around for implementations to see if they commonly return the reduced type, to see the estimated impact of the breaking change
• OR: make this backwards compatible

[chipgpt]

Understood. I can make it backwards compatible. My only argument for changing the type is that it seems like the current type is wrong. As you pointed out, saveClientInformation() takes the OAuthClientInformationFull type and is the only way clientInformation() is set.

[pcarleton]

I thought about this a bit more and chatted w/ @ochafik & @felixweinberger .

There's 2 flows to consider:

• DCR Request + Response
• Saving and restoring client information

For the DCR Request + Response, requiring redirect_uri's in both cases is correct. We require sending one, and the DCR response is required to send back any data related to the client:

Additionally, the authorization server MUST return all registered
metadata about this client, including any fields provisioned by the
authorization server itself.

However, saveClientInformation and clientInformation are used in non-DCR flows as well. In static registration situations, providing the redirect URI's isn't required and are often not available. Similarly, with the upcoming Client ID Metadata Document flow, the list of redirect URI's will not be on the client necessarily.

So what that means is:

• OAuthClientInformationFull could more properly be named OAuthDCRResponseMetadata (or something similar). Although renaming here isn't strictly necessary.
• HaveOAuthClientInformationFull be an optional type for both saveClientInformation and clientInformation
• Also allow OAuthClientInformation as a type in both cases

That will loosen the type to accommodate both DCR and non-DCR cases, and also allow us to get the supported token_endpoint_auth_method in the DCR response if it's available.

[chipgpt]

@pcarleton understood. will follow up

[chipgpt]

@pcarleton I have redone the PR.

• Adds a new type to src/shared/auth.ts:

export type OAuthClientInformationMixed = OAuthClientInformation | OAuthClientInformationFull;

• Applies new type to the auth flow in src/client/auth.ts
• Updates example client src/examples/client/simpleOAuthClient.ts
• Adds tests for selectClientAuthMethod to src/client/auth.test.ts

[frankie567]

Maybe a less intrusive solution would be the following:

const supportedMethods = clientInformation.token_endpoint_auth_method ? [clientInformation.token_endpoint_auth_method] : (metadata?.token_endpoint_auth_methods_supported ?? [])

[chipgpt]

Agreed this is less intrusive, but it has a slightly different behavior. If the metadata has "token_endpoint_auth_methods_supported": ["none"] and the client registration endpoint returns "token_endpoint_auth_method": "client_secret_post", this code would bypass the metadata's "supported" value. Is that allowed?

https://www.rfc-editor.org/rfc/rfc8414.html

token_endpoint_auth_methods_supported
OPTIONAL. JSON array containing a list of client authentication methods supported by this token endpoint. Client authentication method values are used in the "token_endpoint_auth_method" parameter defined in Section 2 of [RFC7591]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].

[frankie567]

Yeah, I guess that's unlikely, but still possible 😊

[pcarleton]

Awesome, LGTM! Thanks for the patience