feat(auth): add token_endpoint_auth_method to OAuthClientConfig#648
Merged
alexhancock merged 8 commits intomodelcontextprotocol:mainfrom Feb 13, 2026
Merged
Conversation
Some OAuth providers (e.g. HubSpot) require client credentials to be sent as POST body parameters (client_secret_post) instead of via HTTP Basic Auth header. The oauth2 crate defaults to BasicAuth, and rmcp had no way to override this, causing TokenExchangeFailed errors. Add an optional `token_endpoint_auth_method` field to OAuthClientConfig that accepts "client_secret_post" (RequestBody) and "client_secret_basic" (BasicAuth). Unknown values are silently ignored, preserving the default. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
github-actions
bot
added
T-core
Move auth method selection from per-client config to server's AuthorizationMetadata, which is the correct OAuth 2.0 approach. Servers like HubSpot advertise token_endpoint_auth_methods_supported in their metadata; reading it from there avoids manual configuration and prevents TokenExchangeFailed errors with non-BasicAuth providers. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ional_fields Move token_endpoint_auth_methods_supported out of AuthorizationMetadata as an explicit field and read it from the serde(flatten) additional_fields HashMap instead. This avoids serializing `null` when the field is absent, which broke Zod validation in downstream consumers like MCP Inspector. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… test assertions When token_endpoint_auth_methods_supported contains both client_secret_post and client_secret_basic, default to basic auth per RFC 6749 §2.3.1. Update configure_client tests to assert actual AuthType instead of is_some(). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Contributor
Author
|
@alexhancock Hi Alex, any chance you can take a look at the PR |
Contributor
Contributor
Contributor
|
@anara123 Do you mind running |
Contributor
Author
|
@alexhancock done. |
Contributor
Sorry I should have specified I will add a precommit check for this |
Contributor
|
@anara123 There is also now a merge conflict, which if you could resolve would be great. Then can get it merged. |
Contributor
Author
|
@alexhancock Sure no problem. Formatted the code as you requested and fixed the conflicts. |
alexhancock
approved these changes
Feb 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some OAuth providers (e.g. HubSpot) require client credentials to be sent as POST body parameters (client_secret_post) instead of via HTTP Basic Auth header. The oauth2 crate defaults to BasicAuth, and rmcp had no way to honor the server's advertised auth method, causing TokenExchangeFailed errors.
Derive token_endpoint_auth_method from the server's authorization metadata (token_endpoint_auth_methods_supported) during configure_client. When the server advertises client_secret_post, the client is set to AuthType::RequestBody; otherwise it defaults to
BasicAuth. No new config fields are added — the behavior is driven entirely by server metadata.
Motivation and Context
OAuth servers advertise supported token endpoint auth methods via token_endpoint_auth_methods_supported in their authorization server metadata. rmcp was ignoring this field, always using Basic Auth. Servers like HubSpot that require client_secret_post would reject token requests.
How Has This Been Tested?
Tested with a simple MCP client connecting to HubSpot's remote MCP server (
https://mcp.hubspot.com/mcp), which requiresclient_secret_postauthentication.Breaking Changes
No breaking changes.
Types of changes
Checklist
Additional context
The TypeScript MCP SDK already implements the same
token_endpoint_auth_methods_supportedpattern:packages/core/src/shared/auth.ts— definestoken_endpoint_auth_methods_supportedinOAuthMetadataSchemapackages/client/src/client/auth.ts—selectClientAuthMethod()readstoken_endpoint_auth_methods_supportedfrom server metadata and picks betweenclient_secret_basic,client_secret_post, ornone;applyClientAuthentication()then sends credentials accordingly (Basic header vs POST body)This PR aligns the Rust SDK with the TypeScript SDK's existing behavior.