Follow my blog for more interesting topics on Dynamics 365, Portals and Power Platform. For training and consulting, write to us at email@example.com
Before I go ahead, while this blog depicts on how you can generate the Authentication token to integrate between Dynamics 365 and SharePoint, this can be applied to any application trying to authenticate with SharePoint online to consume SP REST API’s. The methodology presented here can be applied for all applications.
Your day as a consultant can throw a lot of surprises and this was one of them. We had a custom integration between Dynamics 365 online and SharePoint. online And the connection was being completed using username and password authentication by consuming Sharepoint REST API services.
And one fine day this stopped working. There were some access policy changes on Azure and now the code was not able to generate a request digest using username-password credentials. It was always coming as null and authentication was failing. Moreover client was also not okay to use a service or end-user account for authentication.
If you are on the same boat, don’t be worried. This blog is explicitly on how you can handle this scenario. And that is using SharePoint add-in.
There are multiple ways to register SharePoint add-in such as using Visual Studio, the Seller Dashboard, or an AppRegNew.aspx page. In this blog post we will register add-in using AppRegNew.aspx in tenant which is one of the recommended approaches.
To do this we need global administrator privileges which is SharePoint Administrator role in SharePoint site. Let us now try to register your add-in in the following steps:
Step 1: Go to <site-colleciton-url>/_layouts/15/AppRegNew.aspx using browser.
Step 2: Fill up the details to create add-in
· Client Id – Add in ID basically a Guid that can be generated (Generated button is used to generate Guid) or paste Guid into AppRegNew.aspx
· Client Secret – Add in Secret basically a string that can be generated using Generated button. Usually the secret expires in one year.
· Title – Name of the add in
· App Domain – The host name of the remote component of the SharePoint Add-in. he add-in domain must match the URL bindings you use for your web application. Do not include protocol (“https:”) or “/” characters in this value. If your web application host is using a DNS CNAME alias, use the alias. Examples: www.localhost.com, www.contoso.com:3333 and www.scholarship.com
· Redirect Uri –The endpoint in remote application. The value must be a complete endpoint URL including the protocol, which must be HTTPS. For example: https://www.localhost.com, https://www.contoso.com/Default.aspx
Step 3: Provide all the details and click Create.
Now that we have created the add-in, it’s now time for providing the app the required permissions to your sitecollection. In the next blog will shall be doing the same. Make a copy of your application details that you just created. We shall need it in the next blog.
Hope this helps!