webMethods.io Integration Connector OAuth2 Client Credentials Grant Support

[Jing_Ming_Guo]

Background
As Integration specialists, most of the time, we are not allowed admin access from the IdPs to authorize access to assets which is required to add the “Default” OAuth2 credentials for most of the predefined connectors (e.g. SharepointOnline connector requires Azure AD Tenant Admin access to grant the access using the “default” connection, Salesforce requires Salesforce Admin access to grant the access using the “default” connection). Please see screenshots SharepointOnline Connector Default OAuth Screen1 to 4 attached. Most of the time, as middleware, we are provided with client_credentials grant, no other grant types make sense as we are not a portal for users to login to, nor are we backend servers - we are in the middle and service accounts / client_credentials flow is the norm.
Uploading: SharepointOnline Connector Default OAuth Screen4.JPG…
Uploading: SharepointOnline Connector Default OAuth Screen3.JPG…
Uploading: SharepointOnline Connector Default OAuth Screen2.JPG…
Uploading: SharepointOnline Connector Default OAuth Screen1.JPG…

When you add your own connector the only supported authentication types are OAuth V1.0a, OAuth V2.0, OAuth V2.0 (JWT Flow), all have different fields that do not support Client Credntials grant

Problem
When adding an account using custom OAuth2 type credentials to:

• some Predefined (e.g. Sharepoint); or
• any Custom REST Connectors
  the fields available do not support OAuth2 client_credentials grant type, in other words most typically require (all mandatory):
• Client ID
• Client Secret
• Access Token
• Refresh Token
• Refresh URL
• Grant Type
  e.g. SharepointOnline connector
  
  

Custom Rest connector credentials

Both JWT and Oauth1.0a do not support client credentials grant either

there is no field for scope, which is a requirement for client_credentials grant. I have attached a screenshot for the Sharepoint Online Connector which lists the required fields above, under Grant Type, the tool tip mentions client_credentials, but it should not require the fields access token, refresh token or refresh URL, and requires token url and scope.

Feature Request
In other words, we are hoping to have all predefined connectors and any custom REST connectors to support client_credentials grant which is typically used for integrations. This will require the following fields:

• client_id
• client_secret
• token url
• grant_type
• scope

[emil.blohme1 (Emil Blohme)]

Hello @Jing_Ming_Guo!
Did you get any feedback on this?
I’m currently in the same situation where I want to use client_credentials grant type with the predefined SharePoint Online connector…

Best Regards,
Emil Blohmé

[Jing_Ming_Guo]

Hi Emil,

I’ve met with the R&D team who have advised they are looking into this (along with the custom REST Connector) but we have not been advised when it will be available.

If you need to bypass this, you’ll need to either

1. Use a custom REST connector and have a separate HTTP call to your 3rd party IdP (e.g. AzureAD) to get the token, then call your REST connector
2. I was advused to use the nodejs connector builder with any of the sharepoint online swagger specs, but this requires some nodejs/js knowledge and we did not want to do anything custom for authentication; OR
3. We found a way to get around the token generation by doing the following.
   a. Create a flow service to call your 3rd party IdP to generate your token using client credentials. The response from the provider would include fields like access_token, expires_in or something, just add a refresh_token in the response (can be anything, but I would map the access_token there)
   b. Open this as an API that can only be called by your tenant (so there’s no public access).
   c. put in the authorization URL as the API endpoint you created, the server url should be your sharepoint endpoint and the rest doesn’t really matter unless you want to map in the inputs from to your flow service which adds a layer of security. After this, your connector should be useable.

I would only recommend using the first option for a productionalised release, everything else puts you at risk of not being supported, plus with option 2 and 3, you’re only able to use the integrations in workflows which, in my opinion, is severely limited as I have advised R&D.
Thanks.

[emil.blohme1 (Emil Blohme)]

Hi!
Thanks a lot for sharing. Very valuable insights.
Lets hope R&D team have a fix for this in the near future.

Thanks again!