Oauth2 issue in workflows

Hi,
We are experiencing some issues in workflows with the HTTP Request action, when using oauth2 client credentials when credential location is set to header.

We are making an API call to an external endpoint which has Oauth2 set up through Azure AD. The calls works fine when executing from postman so I am certain the urls and credentials are correct.
However when trying from a workflow in IDN it fails with error:
request failed (type: HTTP Response Returned a Client Error, retryable: false): request failed: 401 - 401 Unauthorized - { "statusCode": 401, "message": "Unauthorized. Access token is missing or invalid. Update"

This is how http request looks:

When I changed credential location from header to body it works. Which verifies that the credentials are correct. But we would prefer to send it in header and it works with header from postman as stated above.

Not sure how I can troubleshoot this. What I can say is that the client secret contains special chars such as ‘~’, ‘.’ and ‘_’. Is there perhaps some limitation in IDN when encoding this to Base64 which I assume it does before sending it to the token url.

Please let me know if you have any ideas or further questions for clarification.

Hey Jesper,
You have oAuthInHeader specified, but you didn’t actually add any headers to the request, at least not in this screenshot. Can you try adding the necessary headers?

-Mark

Hi, to my knowledge the “requestHeaders” which can be filled in is for the actual request to the requestUrl, not related to the first API call made to the oauthtoken url to retrieve the access token, which is what fails.
Or do you suggest would I need to specify in the requestHeader the access token I recieved, if so I have no clue how to do that as requestheader cant use variables as I would need to specify something like $.“oauth call”.response.access_token".
I have never filled in any headers in any API calls I have made in workflows previously I am guessing it fills in content-type, accept etc per default, which works fine. For example when making API calls to IDN itself in another workflow that works looks like this:


and I dont see any difference.

Ah, true. Sorry.

Why would you need to pass in the credentials via headers for the auth call? Per Microsoft’s documentation, the token request should happen in the body: Get access without a user - Microsoft Graph | Microsoft Learn

Subsequent calls would then include the Bearer token in the Authorization header.

Wouldn’t say I need per se, the person who setup the oauth for us just suggested header and I have always done it in header to other API’s. And since it works for me to send it in the header from postman something is strange.
So in short, it is not a deal breaker or anything but wanted to check if anyone have experienced this and suggestions as we might get some other API in the future which only acceps it in header and then if we have the same issues we might know why.

But I guess I might have to create a ticket to support to check logs how the actual calls looks as I they are not provided in the VA.
Thanks for your time!

If I’m understanding the use case, you want to make your own Authorization: Basic XXXXX header, rather than giving IDN the Client ID and Client Secret and letting it do the things via the request body?

You may be able to do this by using the Custom Authorization option and setting your headers in there, but I think you’re reinventing the wheel here and would suggest just using the standard options defined unless otherwise necessary.

Sorry late answer, been busy.
No no, I dont want to do anything custom at all. I want to simply use OOTB behaviour for Oauth2 in IDN. See picture of what does not work:


If I change the yellow marked to body it works fine.
The setup above when doing API calls to IDN itself, get accounts, search or whatever (with different credentials and url ofc) works fine with header (IDN even gives a hint saying header is preferebly used.

So yeah, not sure why it does not work from IDN, as I said, if I do same call from postman with option to send auth details in header it works.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.