What is SharePoint Provider Hosted App/Add-in?

SharePoint provider-hosted add-ins includes components that are deployed and hosted outside the SharePoint farm. They are installed to the host web, but their remote components are hosted on another server.

SharePoint-hosted add-ins has a fixed hosting pattern, since they are hosted on the add-in web. Provider-hosted add-ins provides more flexibility for hosting the various components of your add-in, so if you choose to create one, you’ll need to match your goals and requirements to the appropriate hosting pattern. One of the most important questions you need to ask when considering provider-hosted add-ins and how you’ll build them is how the add-in will get authorization to interact with SharePoint.

Provider-hosted add-ins gives you two choices:

1. JavaScript cross-domain library
2.  OAuth

1. JavaScript cross-domain library:

The cross-domain library lets you interact with more than one domain from the remote components of your add-in through a proxy. If client-side code and the permissions of a user who is signed in to SharePoint are sufficient, the cross-domain library is a good option. The cross-domain library is also convenient whenever you are making remote calls through a firewall.

2. OAuth:

OAuth is an open protocol that enables secure authorization from client applications (desktop, web, and mobile applications) in an easily manageable way. If you plan to build a SharePoint Add-in that runs in a remote web application and communicates back to SharePoint 2013, you will often need to use OAuth. OAuth is required whenever you are calling into SharePoint from a remotely hosted web application that can’t use client-side code (HTML + JavaScript) exclusively.

If you are using Provider-hosted add-in with Azure (Cloud) web deployment and Office 365 then you need Microsoft Azure Access Control Service (ACS) as the trust broker between Azure (Cloud) Web and Office 365 SharePoint site to make it authorize. But if you are deploying add-in in On-premises SharePoint 2013 site then it needs Server certificates along with ACS to enable High-Trust between add-in and SharePoint. These certificates will be installed on SharePoint on-premises server to enables trust between add-in and SharePoint.

The following table lists all of the possible patterns for hosting both the SharePoint components and the remote components of your add-in, along with the trust brokers that are available to you if you’re using OAuth:

SharePoint component location	Remote component location	Trust broker
On premises	In cloud	ACS, certificate
On premises	On premises	ACS, certificate
Office 365 SharePoint site	In cloud	ACS
Office 365 SharePoint site	On premises	ACS

References:

https://msdn.microsoft.com/en-us/library/office/fp179887(v=office.15).aspx