Feature Overview (aka. Goal Summary)

Summary from the customer:
"""
The workflow must be able to: Intercept the incoming azure user token and exchange it at the Azure AD endpoint (/oauth2/v2.0/token) using:

grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion: azure token
client_id / secret: from workflow credentials
requested_token_use: on_behalf_of
scope: downstream API scope Use the new token for subsequent API calls.

Documentation: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow
"""

Goals (aka. expected user outcomes)

Provide requested functionality and configure correctly workflow properties.

Requirements (aka. Acceptance Criteria):

Based on our findings there are no changes needed in OSL.

The grant-type comes from OIDC https://quarkus.io/guides/all-config#quarkus-oidc-client_quarkus-oidc-client-grant-type, using JWT would be the grant-type to choose for the Azure one.

The client ID and secret are also supported by the OIDC client.

Scope as well.

For assertion I do not think that can be set using properties, it looks like it has to have some programming.

Same for requested_token_use; it would have to be passed in the map along with assertion to the OIDC client here I think https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/quarkus/addons/token-exchange/runtime/src/main/java/org/kie/kogito/addons/quarkus/token/exchange/OpenApiCustomCredentialProvider.java#L169

So if we want that to be dynamic, we would have to add properties as well (from which the values will be retrieved).