Hello,
I am trying to configure a connector to interact with the API of a Microsoft Dynamic CRM instance, but am stuck at the OAuth2 configuration. Here's what I'm facing:
I am using the Web Location connector type,
Configuring the auth and token endpoints as well as the redirect URL, the client_id and the secret, as evident from the screenshot below
not configuring any scope or additional url parameters
When trying to fulfill the initial authentication and authorization, the browser returns an error message indicating that the request body needs to contain the grant_type parameter (specifically: grant_type = client_credentials). However, while the connector cofig interface allows for URL parameters and request headers, I see no option to configure request body elements. Any ideas on how to solve this, or on workarounds to try?
{"error":"invalid_request","error_description":"AADSTS900144: The request body must contain the following parameter: 'grant_type'.\r\nTrace ID: 6dba2c06-793a-4ce6-82c7-da5456900d00\r\nCorrelation ID: 01f68eac-4f10-4c7f-976d-00e682661b1a\r\nTimestamp: 2021-12-08 12:08:14Z","error_codes":[900144],"timestamp":"2021-12-08 12:08:14Z","trace_id":"6dba2c06-793a-4ce6-82c7-da5456900d00","correlation_id":"01f68eac-4f10-4c7f-976d-00e682661b1a","error_uri":"https://login.microsoftonline.com/error?code=900144"}
Hi Dmitry,
thanks for the quick reply. I tried it (both with ‘client_credentials’ as per the error message, and ‘client_authentication’ as per your screenshot) but the error message remains unchanged.
I also replicated the authorization call with Postman. Only when I add the grant_type to the request body, the call is successful and the access_token is returned:
Maybe a bit more context on what exactly I am doing:
We have been interacting with the Dynamics API for quite some time now (i.e. 18 months or so) using primarily EasyMorph
With the initial setup of the connection to Dynamics, we faced the same issue as described above. However, until now we manually handled the token renewals within a dedicated EasyMorph process. Specifically, we updated the connector repo .sqlite with the new token, after performing the call below (note the grant_type in the request body) which returned the same response as in the Postman screenshot above. This allowed all projects that made use of this connector to always have an updated token at hand.
Since v5.0, I know this approach won’t work anymore as the .sqlite is encrypted. So that’s why I’m re-trying to implement the OAuth2, but still facing the authorization process that Microsoft requires, in particular the information to be passed in the request body.
Just to provide some context, as it might be useful to other users / community members.
Oh, my bad. It should've been 'client_credentials' in the screenshot, not 'client_authentication'. Anyway, it didn't work.
Thanks for the clarification, David. In this case, it looks like you don't need to use OAuth at all. Just make the same request as you did with version 4 in order to obtain the token. Extract the token from the response (e.g. using jsonvalue()) and use it in the consequent requests in the workflow with the "Authorization" header as follows:
Authorization: Bearer <your token>
Notice that you should add Bearer in front of the token (notice the space between "Bearer" and the token).
The calculated header value can be used in the "Web request" action using a first column value, or a parameter.
According to the screenshots, the token is valid for 1 hour. Therefore if your workflow takes less than 1 hour to accomplish, this approach should work because every workflow run will obtain a new token.
Hi Dmitry,
thanks, that’s certainly a good solution and I just tagged your answer as such.
There’s one drawback though: in my case there are multiple projects that make use of the same Dynamics API. Hence, any modification to the token request process would imply that I need to modify each of these projects. (Come to think of it, I might centralize this process in a separate .morph project that returns this token as the result table; and subsequently call this project via the ‘Call another module/project’ action in each data process that makes use of this Dynamics API - have to try that one).
Nevertheless, what is your vision on
the direct interaction with the connector repo .sqlite after v5.0 - would you for instance allow the repo encryption to be optional (note: I wouldn’t recommend not encrypting the repo, but it might be useful in certain cases) or (preferably) provide a way to interact directly with the encrypted .sqlite?
allowing more customization in the OAuth process (e.g. allowing to specify a body). To be clear, I’m absolutely no fan of deviating from the standard OAuth flow, but I have encountered at least two cloud apps where the OAuth implementation was non-standard. In one case for instance, the application did not allow other parameters than grant_type, client_id, client_credentials, scope and state. Including e.g. nonce as a url parameter led to an error message.
These aren’t necessarily feature requests, and there’s certainly good reason to handle both points with caution, but they illustrate some of the issues I’m facing and I’m curious on your opinion.
The repo encryption will remain non-optional. We don't want to leave anything that can potentially weaken repo security.
Actually, the OAuth flow in Microsoft Dynamics API does look standard. It's just that EasyMorph doesn't support out of the box this type of OAuth flow yet. The OAuth standard describes many flows - device flow, credentials flow, certificate flow, etc. The API seems to implement the credentials flow. Our initial thinking was that this flow can be arranged as I described above so it's not a priority. However, it appears that we nevertheless should add native support for this flow in the OAuth connector and we will do it in one of the future versions.
