Implement support for client_credentials and RFC 7523

[LucaButBoring]

Implements support for the client_credentials flow over client_secret_basic/client_secret_post. Requires the client to explicitly declare support for the client_credentials grant type, as demonstrated in the example code.

Motivation and Context

Enables machine-to-machine auth and using IdPs that don't support a code grant flow.

How Has This Been Tested?

Added an example that integrates with Discord using this flow. The example does not use Dynamic Client Registration because the OAuthProvider boilerplate that offers that has the authorization code grant flow baked into it right now. Instead, a dummy client ID and client secret are hardcoded in the TokenStorage implementation.

Breaking Changes

• Possible breaking change? OAuthClientInformationFull.client_id is now optional as described in the OAuth 2.1 specification, section 3.2.2.

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

#709

[SoldierSacha]

I also implemented this, along with the token exchange grant type in addition to client credentials

#882

[LucaButBoring]

@pcarleton @dsp-ant Let me know if I should close this in favor of #882, or if the credential grants should be PR'd separately (whether that looks like #882 being split or scoped down to token_exchange). There is also now an SEP that would benefit from either PR to satisfy the implementation example requirement.

[LucaButBoring]

Added a client implementation of RFC 7523 to support SEP-1046. I'll add a server implementation within the next few days.

[LucaButBoring]

Changes:

1. @yannj-fr added support for the RFC 7523 S2.2 flow (client_credentials with an assertion)
2. I've temporarily removed the example code as it was using Discord as an example, and as of Remove github from auth examples #1011 I believe we do not want to use external integrations as examples anymore

---

Unsure about if we should have a server implementation now, reviewing the last core maintainer meeting notes: modelcontextprotocol/modelcontextprotocol#1061

Authorization Server Implementation in SDKs Paul Carleton questioned whether SDKs should provide a fully functional authorization server, leaning towards not providing one due to maintenance overhead. Nick agreed, stating that client-side OAuth implementation is crucial, but implementing an OAuth server is less important as it is often handled by external technology. Den Delimarsky also cautioned against implementing an authorization server within the SDK due to security complexities and potential breach risks.

As a practical matter, that guidance complicates testing, however.

edit: Discussing alternatives on Discord.

[ochafik]

Hi @LucaButBoring, thanks for your PR!

After chatting w/ the team it would seem indeed that something along the lines of #882 would reduce the maintenance complexity (changes encapsulated in httpx.Auth), although it's still TBD whether we do want to onboard these features (pending discussion / decision on modelcontextprotocol/modelcontextprotocol#1046).

Closing this for now (thanks again!), but do let me know if you feel strongly otherwise ✌️

[LucaButBoring]

Sounds good, I believe in the future we want to start using authlib or similar for adding new OAuth support anyways, so a future iteration of this PR (JWT-specific) will likely be rewritten with that anyhow.