SharePointOnlineCredentials versus Azure Active Directory Apps versus ACS Apps

Hi,

I’ve just posted a tip on how to consume CSOM with Azure Active Directory Apps and behind that tip, there is a broader question regarding the various ways to interact with SharePoint Online. Today, we have three possible methods:

  • SharePointOnlineCredentials
  • SharePoint Add-Ins (here I’ll be targetting Provider-Hosted Apps only)
  • Azure Active Directory Apps

SharePointOnlineCredentails
When you write a job, a console program, a PowerShell script etc…you can always instantiate a ClientContext object and use SharePointOnlineCredentials to authenticate. For instance, using the following code:

SecureString ss = new SecureString();
foreach(char c in "a password")
{
   ss.AppendChar(c);
}
using (ClientContext ctx = new ClientContext("https://eyskens.sharepoint.com/"))
{
   ctx.Credentials = new SharePointOnlineCredentials("auser@tenant", ss);
   ctx.Load(ctx.Web.CurrentUser);
   ctx.ExecuteQuery();
   Console.WriteLine(ctx.Web.CurrentUser.LoginName);
}

This method works fine providing the user is granted proper authorization for the target site. However, this method can pose the following problems:

  • You must grant access to every site collection your job/program needs to interact with. So, if you’re using the account techaccount@…., you should specify him as Site Collection Administrator everywhere. If users are themselves Site Collection Administrators, they could remove that guy from the administrators list. You also need to plan adding that technical account for every newly created site collection.
  • You shouldn’t bind that role to a real user. Therefore, you’ll create a technical account. Usually, in a federated scenario, these won’t be synchronized by the dirsync/ad connect/whatever sync method…because usually, only actual end users are synchronized. Of course, you can create Cloud Only accounts for technical accounts but it’s maybe not the cleanest solution.

So, SharePointOnlineCredentials shows its limits in terms of maintenance and management.

SharePoint Add-Ins
With Provider-Hosted Apps, you can either use the App+User policy, either use the App Only policy. If you grant an App a Tenant Full Control permission, the App will be able to come back to any site collection belonging to your Tenant. While this is already great, there are some problems specific to the App Only Policy as depicted in SharePoint App Policy Only calls cannot access draft items even with full-control access. Another potential problem with the Add-Ins is when you need to renew the Client Secret. This is quite tedious and secrets are recorded within SharePoint. By the way, anyone can register Apps (not authorize but at least register) which can also lead to run out of control. Here again, as for the SharePointOnlineCredentials technique, end users might be able to revoke App Permissions by simply going to Site Settings => App Permissions and delete the App of their choice. In a scenario where you need to remotely access SharePoint resource in a background task, this can be a show stopper!

Azure Active Directory Apps
With Azure Active Directory Apps, you can easily add the SharePoint Online permission and enable both Delegate and Application permissions. The advantage of AAD Apps mainly resides in the fact that they are neutral, they can be used the same way to access any SaaS resource. In the context of SharePoint, you can grant your App Access everywhere via the Have full control of all site collections permission. You can do the same with an Add-In but to me, where the AAD Apps make the difference is regarding authorizaiton management, token expiration and secrets management. Authorizations can only be granted/revoked by the administrator of the Office 365 Azure Active Directory. Unlike the two other techniques, end users cannot revoke/delete any account/app permissions. On top of that, Azure allows for a very flexible and secure way of handling those secrets and keys via the Azure Key Vault. The natural integration between Azure Active Directory and Azure Key Vault makes it a prefered method to handle and secure secrets. Moreover, the applications that use those secrets do not need to update anything, they’ll still point to the same Azure Key Vault resource.

So, unless you really need to install the Add-In inside of SharePoint and leverage an App Web or create a “à la carte” service for end users or unless you use SharePoint to control who can access a given App, you’d better user AAD when it comes to background processes that must interact with SharePoint. I’m particularly thinking of web jobs and any remote application that need to consume SharePoint resources.

Happy Coding!

Advertisements

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure Active Directory, Office 365, SharePoint Online and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s