Expose client_secret as an optional field in OAuth2 Token Exchange connection UI

In watsonx Orchestrate, when configuring an OAuth2 Token Exchange connection, some Identity Providers and token endpoints require a client_secret as part of the token request.

Today, client_secret is not exposed as a dedicated field in the connection UI. The supported approach is to provide it manually through the Token Request additional/custom parameters.

For example, with Microsoft Entra ID using the /oauth2/v2.0/token endpoint, our configuration requires additional parameters such as:

requested_token_use=on_behalf_of
client_secret=<application secret>
scope=https://graph.microsoft.com/.default

This works, but the current UI makes the configuration less intuitive because client_secret is a common OAuth parameter and administrators may not know that it must be added manually as a custom Token Request parameter.

IBM Support and the development team confirmed that using the additional Token Request field is currently the supported configuration and mentioned that exposing client_secret as an optional UI field is being considered as an enhancement.

Proposed enhancement

Add Client Secret as an optional field in the OAuth2 Token Exchange connection configuration UI.

The field should:

• remain optional, since not all IdPs/token endpoints require it;
• be stored as a secret/credential and never displayed in clear text after configuration;
• be included automatically in the token request when configured;
• coexist with the existing additional/custom Token Request parameters for IdP-specific parameters such as resource, requested_token_use, etc.

The existing custom parameter mechanism should remain available for advanced configurations.

Business value

This would make OAuth2 Token Exchange configuration significantly easier and less error-prone, especially for common Identity Providers such as Microsoft Entra ID.

It would also:

• make the expected OAuth configuration clearer to administrators;
• reduce configuration mistakes and support cases;
• avoid placing a sensitive credential in a generic custom-parameter section;
• provide a more consistent experience with other OAuth connection types;
• improve the usability of OBO scenarios where watsonx Orchestrate invokes tools on behalf of the authenticated user.

Additional context

We encountered this while implementing an On-Behalf-Of integration between watsonx Orchestrate and Microsoft Graph.

The configuration works when client_secret is supplied through the Token Request custom parameters, but having a dedicated optional field would make the configuration much clearer and easier to maintain.