### 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](https://datatracker.ietf.org/doc/html/rfc8693). There is no authenticator that supports Token Exchange. The `oauth2clientauth` extension currently only supports the base OAuth2 Client Credentials flow defined in [RFC6749](https://datatracker.ietf.org/doc/html/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](https://datatracker.ietf.org/doc/html/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.