Best way to deal with the Azure ACS retirement in a provider hosted Sharepoint Add-in?

terryr 1 Reputation point

I have a provider hosted Sharepoint Add-In that authenticates via Azure ACS, using the process that is currently outlined in the Microsoft documentation. I am aware that for a new tenant, add-ins that are developed in this way will not work out of the box, but will require the tenant admin to set DisableCustomAppAuthentication to false before they can be used (more info here

I know that the recommended solution is to switch over the auth to use Azure Active Directory. I have set up an Active Directory application for this, however I am a little unclear about how to incorporate this into the add-in. The Sharepoint Add-in documentation has not been updated to highlight what config changes are required for the user to give permission to the new Azure Application during the install. I am also unsure if all add-ins should now be high-trust as the recommended auth in Azure Ad is certificate based. The documentation states that high-trust should be reserved for on-premises add-ins, with low-trust still being recommended for provider-hosted add-ins.

Has anyone gone through this process before? Is switching to use Azure Active Directory the best solution? How does one incorporate this into the Add-in? Any advice would be greatly appreciated.

A group of Microsoft Products and technologies used for sharing and managing content, knowledge, and applications.
9,141 questions
0 comments No comments
{count} votes

5 answers

Sort by: Most helpful
  1. sadomovalex 3,621 Reputation points

    so before for communicating with SPO you have to register your app via appregnew.aspx (where you get clientId and clientSecret) and then grant permissions to this app via appinv.aspx (using xml request).

    In new approach you register add in Azure AD (Azure portal > AAD > App registrations) first. After that go to API permission tab of this app and add necessary permissions for Sharepoint: it may be app permissions or delegated (since you mentioned DisableCustomAppAuthentication I assume that you use app permissions). After that grant Admin consent on the same page if needed. E.g. if you need full control on all site collections permissions may look like that:

    After that you have to choose how you want to authenticate using this app: using clientSecret or certificate. Both are configured on Certificates & secrets tab of the app. Client secret is simpler but is considered outdated. MS recommends to use cert-based authentication: it is little bit more complex to configure - see Granting access via Azure AD App-Only.

    1 person found this answer helpful.
    0 comments No comments

  2. MichaelHan-MSFT 17,996 Reputation points

    Hi @terryr ,

    According to this documentation, there are two approaches for doing app-only for SharePoint:

    • Using an Azure AD application: this is the preferred method when using SharePoint Online because you can also grant permissions to other Office 365 services (if needed) + you’ve a user interface (Azure portal) to maintain your app principals.
    • Using a SharePoint App-Only principal: this method is older and only works for SharePoint access, but is still relevant. This method is also the recommended model when you’re still working in SharePoint on-premises since this model works in both SharePoint on-premises as SharePoint Online.

    So yes, AAD app is the recommended way for you. And to use AAD app to access SharePoint, you could use AuthenticationManager Class in the SharePoint PnP Sites Core library to get client context object. More details are in this article: Granting access via Azure AD App-Only

    If an Answer is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    1 person found this answer helpful.
    0 comments No comments

  3. sadomovalex 3,621 Reputation points

    those app which you've registered through appregnew.aspx will appear in Azure portal > AAD > Enterprise applications search. However based on my test permissions granted via appinv.aspx and xml permissions request won't be shown there:


    It may mean that those permissions are not automatically mapped on AAD permissions. In this case it is simpler to recreate new AAD app, grant permissions in Azure portal and then use this app instead of old one:

    1 person found this answer helpful.

  4. terryr 1 Reputation point

    Hi @sadomovalex & @MichaelHan-MSFT ,

    Thanks you both for the replies, they were useful. One quick follow up question. How do I tie the Add-In, that I have created and registered via appregnew.aspx, to my new Azure Active Directory Registration? Does it just automatically have access if it requires the same permissions as those requested by the Add-In in xml? I am unclear about what config changes I am required to make in my Add-in. Should the id of the AAD be added to the Add-in configuration somewhere?

    Thanks ,


    0 comments No comments

  5. terryr 1 Reputation point

    @sadomovalex @MichaelHan-MSFT any more thoughts on this one? I am starting to think that it is not possible to get an add-in created in this way (
    ) integrated with Azure AD. If either of you could confirm that my assumption is correct it would be very helpful. I am blocked on this at the min and want to be sure that this is not possible before looking for alternative solutions.

    I appreciate the help.

    0 comments No comments