Connecting to Dynamics 365

[GeoffreyH]

Hi,

We're investigating Talent and we're trying to connect to Dynamics 365 using the tMicrosoftCRMInput component.

1. Why does the component require a username and password as well as an application/client id and secret?
2. I'm also getting the following error when running the job.

javax.naming.AuthenticationException: com.microsoft.aad.adal4j.AuthenticationException: {"error_description":"AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.\r\nTrace ID: 5ef6e209-ed9c-4353-8dcb-3d6766421900\r\nCorrelation ID: caba45f3-1fad-4088-8066-a853f2da55a0\r\nTimestamp: 2022-01-26 19:59:12Z","error":"invalid_client","error_uri":"https:\/\/login.microsoftonline.com\/error?code=7000218"}

Our application user is setup with the correct permissions and we get an OAUTH token etc in Postman with no issue.

[Anonymous]

I'm afraid I do not have access to Dynamics 365 at the moment, but I have done a bit of reading around this and can maybe either point you in the right direction OR gain a bit more info to investigate further.

First of all, did you follow the documentation here?

https://help.talend.com/r/en-US/8.0/microsoft-crm/retrieving-settings-of-application-open

If not, can you take a look and see if that helps.

With regard to the username and password as well as the application/client id and secret, this will be because the flow of OAuth 2.0 is usually a multi-step process with user interaction. I've written a few blogs on accessing OAuth 2.0 resources using the tRestClient component when there isn't a component built to handle this. In this case, the component will be handling the whole process of accessing your token and for that it needs to "login" for you when the OAuth Authorisation Endpoint is utilised.

If you could go through the documentation I have pointed you to and let me know how you get on. Sorry I've not been able to try it first, but I figured it didn't hurt to point you to this.

[GeoffreyH]

We've done all that but our application only has a client id and secret, there is no separate username and password.

We use the client id and secret for OAUTH2 using the client_credentials OAUTH flow to generate an access token. There is no need for an additional username or password in this flow.

I was hoping to avoid having to use the REST client to generate request an OAUTH token we cache and add to an authorisation header for requests. We've already had to do this for previous platforms we've investigated.

[Anonymous]

It doesn't look like we currently support that flow unfortunately. However, one of the key advantages of Talend is that whatever isn't supported or provided out of the box can be built by using our component creator kit or by simply writing a routine (in Java) and using it in your jobs. I understand that this may not be ideal in this scenario, but whatever is possible in Java is possible with Talend. You can also go through the REST process to generate an OAuth token with a reusable job if you'd like to do it that way.

I think that this is a feature that we should support. You can raise a Jira if you like. You can sign up for Jira access here:

https://login.talend.com

Then go to our Jira site which is here:

https://jira.talendforge.org/

Explain your requirement in as much detail as you can and it will be considered. If you post the Jira URL here, I will vote for it and get as many of my colleagues to vote for it as I can.

Sorry that this is not the answer you were hoping for, but as I said, there will be a reusable way around this with Talend Studio.

[GeoffreyH]

Thanks for your help. It seems client_credentials is not an OAUTH2 workflow that appears to be widely supported by any platform for some reason unfortunately.

I don't understand why a user/password focussed OAUTH workflow seems to be the dominant OAUTH2 method for integration platforms when application id/secret is simpler.

[Anonymous]

I believe this is likely to be due to the fact that the client_credentials route is a lot newer. I know when I started working with OAuth 2.0 (doing it all manually with tRestClient calls) I had to go through the process of generating a URL, calling the URL in a browser, signing-in and then taking the returned URL back and getting the token from subsequent calls based on that. That was a while ago and things have moved on. I have no doubt that the newer methods will arrive, but it can take a bit of time to get this built in....especially if there is a working solution already. The more noise that is made about it from customers (or prospective customers), the quicker it is likely to bubble to the top of the request queue.