Finalizer supporting OAuth 2.0 Token Exchange (RFC 8693)

Preflight checklist

[X] I agree to follow this project's Code of Conduct.
[X] I have read and am following this repository's Contribution Guidelines."
[ ] I have discussed this feature request with the community.

Describe the background of your feature request

One of the options to pass the information about the authenticated and authorized subject to the upstream service availablel today is a built-in Security Token Service (STS), implemented by the jwt finalizer.

It allows exchanging any authentication information used by the client (tokens, cookies, etc) for a highly customizable JWT that the heimdall instance itself signs and provides the keys via the jwks endpoint to verify. Even that approach is useful for implementing edge-level access control architecture, it leads to transparency loss in the identity management flow as heimdall becomes a token issuer authority, which might be challenging or even unwanted in particular setups.

Describe your idea

To still have the above written functionality without heimdall being a central actor in the identity management flow, a new finalizer supporting the OAuth 2.0 Token Exchange protocol (RFC 8693) would be helpful. The finalizer type could be named e.g. oauth2_token_exchange.

Pros & Cons to be considered:

By making use of the OAuth 2.0 Token Exchange protocol, flexibility supported by the jwt finalizer (ability to define claims that end up in the new token) will be lost to some degree.
New tokens can be issued via a standard protocol established for that purpose.
That new finalizer can most probably only be used in combination with authenticators acting on OAuth2/OIDC protocol.
Hemdall is not a central actor in the identity management flow any more

dadrus / heimdall