Description
Component(s)
extension/oauth2clientauth
Is your feature request related to a problem? Please describe.
We need the collector to interact with a Security Token Service (STS) implementing OAuth 2.0 Token Exchange defined in RFC8693.
There is no authenticator that supports Token Exchange. The oauth2clientauth extension currently only supports the base OAuth2 Client Credentials flow defined in RFC6749.
Describe the solution you'd like
I would like to extend the oauth2clientauth extension to support Token Exchange in addition the existing Client Credentials flow.
Rationale
Although the RFC for Token Exchange adds additional specifications on top of RFC6749, most of the client side behaviour remain the same and is compatible with the base authentication flow. Most of the specification is regarding server side behaviour and how it should produce/handle the STS token.
Specifically, the only change that concerns our extension is calling the oauth2 endpoint with different parameters (subject_token instead of client_id and secret. Even this can be delegated to the oauth2 library -- we just need to provide it with the correct input.
We can easily abstract away this difference and load either a client_id/secret pair for base Oauth2 flow or by loading a subject_token for token exchange and call the corresponding functions in the oauth2 library. Everything after this remains the same, since we do not need to distinguish the returned Token and can derive the necessary functions such as PerRPCCredentials just like we are doing now.
Describe alternatives you've considered
Alternatively, we can create a new extension, for example oauth2stsauth or oauth2tokenexchangeauth. However, given the high level of overlap between Token Exchange and the base two-legged flow in how it's used for a telemetry agent, it makes more sense to me to save the overhead of creating yet another extension.
Additional context
I'm willing to draft up and contribute the code. I can write up a more detailed design proposal on the abstractions, changes, etc. as long as there are no initial objections against the core idea of using the same extension for both the default flow and Token Exchange mode.