-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Implement support for client_credentials
#1020
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?
Implement support for client_credentials
#1020
Conversation
I also implemented this, along with the token exchange grant type in addition to client credentials |
…-sdk into feat/client-credentials
@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 |
Implements support for the
client_credentials
flow overclient_secret_basic
/client_secret_post
. Requires the client to explicitly declare support for theclient_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
OAuthClientInformationFull.client_id
is now optional as described in the OAuth 2.1 specification, section 3.2.2.Types of changes
Checklist
Additional context
#709