Client Credentials Grant #6
Merged
Conversation
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
SailReal
reviewed
Oct 27, 2023
SailReal
approved these changes
Oct 27, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This adds support for the Client Credentials Grant type, allowing utilization of this lib for daemons aka service accounts that authenticate without user interaction.
Implementation details:
In respect to RFC 6749, Section 2.3.1, we use the Basic Authentication Scheme to transmit the client credentials. This is the recommended method and other than using body parameters it MUST be supported by all compliant Authorization Servers.
RFC 7617 amends older standards for Basic Auth in regards of specifying a charset. While UTF-8 is a de-facto standard and a recommended fallback, the encoding of credentials may depend on using the correct charset. So this lib allows specifying a credentials charset.
RFC 6749, Section 6 specifies that authentication is also required during token refresh:
As adhering to this specification is likely to requires an API change, this implementation is currently wilfully violating this specification. Should a token refresh using the Client Credentials Grant type ever be required downstream, we need to add it.