-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Adding Client Credentials & Token Exchange Grant Types to Auth #882
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Adding Client Credentials & Token Exchange Grant Types to Auth #882
Conversation
…for-oauth-client-credentials Add OAuth client credentials grant
…mplement-client-credentials-support Fix auth registration for client credentials
…mentation-of-client-credentials-flow Refactor auth helper methods
Fix failing tests and pyright
…eerror-in-pytest-test-case Fix OAuth tests using async fixtures
Fix resumption token update logic
Add OAuth token exchange support
…change-implementation-for-test-failures Fix token exchange metadata tests
Reported-by: sachabaniassad
Fix pyright case issues in tests and example
Fix resumption token whitespace handling
Went ahead and updated the PR to also support the Token Exchange grant type (in addition to Client Credentials). This is ready to be merged!! This PR is a huge win for this community. @dsp-ant @jspahrsummers @calclavia @nick-merrill @jerome3o-anthropic |
Please review this for merge... tired of keeping it in sync with current repo!!! @Kludex @pcarleton @simonw @sheffler @comfuture @shimizukawa @ihrpr @dsp-ant @jspahrsummers @calclavia @nick-merrill @jerome3o-anthropic |
…ant type. Support client_credentials+token_exchange
I have some questions:
|
|
Handle closed stream when sending notifications
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
Checklist
Additional context
No