OAuth Update: Adding the Client Credentials & Token Exchange Grant Types

[SoldierSacha]

Motivation and Context

#881

In addition to adding the Client Credentials grant (from the issue linked above), I've also gone on to add the Token Exchange grant.

Reasoning for Token Exchange: Since the client credentials grant is for machine-to-machine authorization, I realized that there are times where the client machine (acting as an MCP Client) might have to make requests on behalf of an end-user to the MCP Server. With that being said, in the current implementation, this did not exist because there was no way to securely identify the end-user.

Now it does through Token Exchange.

How Has This Been Tested?

Added test cases (all pass), and also currently using in my own mcp server and client. Everything is working as intended.

Breaking Changes

None

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

No

[SoldierSacha]

@simonw @sheffler @comfuture @shimizukawa @ihrpr

[SoldierSacha]

@Kludex @pcarleton

[LucaButBoring]

Since #1020 was closed, I took a look at the code here, leaving a few comments:

1. We should avoid duplicating dynamic client registration code and metadata discovery.
2. Client credentials has client_secret_post and client_secret_basic variants which should both be handled (this PR currently assumes client_secret_post without checking).
3. The authorization_code, client_credentials, and token_exchange flows should probably all extend a new base class, instead of making ClientCredentialsProvider extend httpx.Auth and making TokenExchangeProvider extend ClientCredentialsProvider.

[SoldierSacha]

Since #1020 was closed, I took a look at the code here, leaving a few comments:

1. We should avoid duplicating dynamic client registration code and metadata discovery.
2. Client credentials has client_secret_post and client_secret_basic variants which should both be handled (this PR currently assumes client_secret_post without checking).
3. The authorization_code, client_credentials, and token_exchange flows should probably all extend a new base class, instead of making ClientCredentialsProvider extend httpx.Auth and making TokenExchangeProvider extend ClientCredentialsProvider.

Thank you for your comments! In my recent commits, here's what I changed to address your concerns.

1. I went ahead and implemented a shared BaseOAuthProvider that centralizes OAuth server discovery and dynamic client registration logic. This BaseOAuthProvider provides reusable helpers for all grant types.

2. I added _apply_client_auth to support both client_secret_post and client_secret_basic when authenticating to the token endpoint.

3. The token exchange is now refactored to derive from the new base class (BaseOAuthProvider) and default the resource parameter using the server URL.

[felixweinberger]

Hi @SoldierSacha thanks for this contribution! And apologies for the time it took to get back to this.

I checked with @pcarleton and it looks like this change is still pending SEP-1046: modelcontextprotocol/modelcontextprotocol#1047

I'm going to request changes for now as there will still be merge conflict resolution and potentially minor changes needed once that SEP is accepted.

[SoldierSacha]

Hi @SoldierSacha thanks for this contribution! And apologies for the time it took to get back to this.

I checked with @pcarleton and it looks like this change is still pending SEP-1046: modelcontextprotocol/modelcontextprotocol#1047

I'm going to request changes for now as there will still be merge conflict resolution and potentially minor changes needed once that SEP is accepted.

Thanks for the update, @felixweinberger!

Understood — I’ll keep an eye on SEP-1046. Once that’s accepted and merged, I’ll rebase again and make any necessary adjustments.

For now, I’ve gone ahead and updated this branch with the latest changes from main to keep it current and reduce future conflicts.

Appreciate the review!