Provider-Hosted Apps vs. Microsoft Azure Applications

Scot Hillier

by Scot Hillier on 6/19/2014

Share this:

Article Details

Date Revised:

With the recent end of the autohosted apps preview and introduction of the Office 365 APIs, SharePoint developers may find themselves somewhat confused regarding their cloud development options. After a significant learning investment in the app model, developers discover the landscape has been shaken. When the dust settles, however, three hosting models are left for SharePoint development: SharePoint-hosted apps (SHA), Provider-Hosted apps (PHA), and Microsoft Azure applications (MAA). It’s important to understand the differences between these app models so you can decide when and how to use each. For this article, however, I’ll concentrate on the cloud-based hosting models embodied in PHA and MAA applications, which are taking on increasing importance since the end of the autohosted apps preview.

Ok. I just made up the three-letter acronym (TLA) MAA. But I like it, and I’m gonna use it throughout the article!

Because PHA development has been available since SharePoint 2013 released, the new kid on the block for most SharePoint developers is the MAA, which represents the next wave of SharePoint development. Microsoft Azure applications are unique because they don’t require the developer to explicitly register a Client ID with SharePoint. Instead developers create standalone applications in Microsoft Azure that utilize OAuth tokens to access required SharePoint resources. This model allows an end user to access a standalone application directly – without launching it from SharePoint – but still gain access to their SharePoint assets.

This model strengthens the idea that SharePoint is a software service that your applications can utilize like any other service available in the cloud. It also opens the SharePoint platform to non-SharePoint developers who are familiar with OAuth and REST but couldn’t care less about CAML and CSOM.

To understand how SharePoint developers can leverage Azure applications, you can compare a PHA launched from Office 365 (O365) with an MAA accessed directly in the browser. In each case, user authentication and application authorization are the focus. This should give you a better understanding of how the pieces fit together and which option makes the most sense for a given situation.

User Authentication

Regardless of whether you choose to deploy a PHA or an MAA, users must be authenticated before they can be granted access to SharePoint resources. Although the authentication flow is different, both the PHA and the MAA will ultimately authenticate users against Microsoft Azure Active Directory (AAD). AAD is the repository for O365 user accounts (a.k.a, Organizational Accounts) that acts as a Security Token Service (STS). Users log in to O365 using their Organizational Identity. Similarly, users can log in to an MAA using the same credentials.

PHA Authentication

Before users can access O365 using an Organizational Identity, the O365 administrator must give them permission. This is a straightforward process, so I’ll skip the details.

When a user subsequently logs in to O365 using an Organizational Identity, the following sequence occurs:

  1. The user opens a browser and attempts to navigate to a SharePoint Online site.

  2. The user is redirected to and is presented with a login screen.

  3. The user enters credentials and submits the form.

  4. If the authentication is successful, a Security Assertion Markup Language (SAML) token is returned.

  5. The user is redirected to SharePoint Online to validate the token.

  6. If the token validates, the user receives a FedAuth and rtFa cookie.

  7. Each subsequent request to a SharePoint resource includes the FedAuth and rtFa cookies for authentication.

MAA Authentication

Before a user can access an MAA using an Organizational Identity, the application must first be registered with the AAD associated with O365. This is typically done using the Microsoft Azure portal, which requires a Microsoft Azure subscription. An Azure subscription is separate from an O365 subscription, but it can be used to manage the AAD associated with the O365 subscription. In order to manage your O365 directory in the Azure portal, follow these steps:

  1. Log in to an existing Microsoft Azure subscription as the administrator.

  2. Click on the Active Directory link.


  3. Click New>>Active Directory>>Directory>>Custom Create 


  4. Select to Add an Existing Directory       

  5. Follow the steps to add an existing directory using an Organizational Identity with administrator rights in O365.

After the O365 directory is added to the Azure subscription, you will also need to add the Organizational Account for the O365 directory as a co-administrator of the Azure subscription. This will allow you to log in to the Azure subscription with the O365 account so you can manage applications. You can add a co-administrator by using the following steps:

  1. Log in to an existing Microsoft Azure subscription as the administrator.

  2. Click the Settings link.        


  3. Click Administrators

  4. Click Add.

If you are using an Organizational Account to log in to an Azure subscription, you may receive the error that “no subscriptions are associated with this account.” If you do, simply use the organizational account to sign up for a trial Azure account. This is a roundabout way of gaining access to Azure that should be fixed in the future.

Once the O365 directory is available in the Azure portal, you can create new ASP.NET (MVC or web forms) applications that utilize the Organizational Accounts from O365. This is done by selecting Organizational Accounts as the authentication mechanism in a new ASP.NET application project. Then simply fill in the dialog with your O365 tenant information as shown:


When a user subsequently attempts to use an Organizational Identity to access your MAA, the following sequence occurs:

  1. The user opens a browser and attempts to navigate to the home page of the application.

  2. The user is redirected to and is presented with a login screen.

  3. The user enters credentials and submits the form.

  4. If the authentication is successful, a SAML authentication request is returned.

  5. The user is redirected to AAD at the endpoint to process the authentication request.

  6. If the authentication is successful, a SAML security token is returned.

  7. The SAML security token is posted to the MAA for validation.

  8. If the token validates, the user receives a FedAuth and FedAuth1 cookie.

  9. Each subsequent request to an application resource includes the FedAuth and FedAuth1 cookie.

Application Authorization

User authentication is only part of the story for SharePoint developers because the whole point is to be able to access SharePoint resources like lists and libraries from within the application. In order to accomplish this goal, the application in question must be authorized to access SharePoint resources. While both a PHA and an MAA will ultimately use a bearer token to gain access to SharePoint, the configuration and authorization flow will be different for PHA and MMA.

PHA Authorization

When you create a PHA in Visual Studio 2013, that application must be registered with SharePoint using a Client Id and Client Secret. In Office 365, this means that the application is registered with Azure Access Control (ACS), which is a STS for application authorization. It is ACS that ultimately issues a token the PHA can use to access SharePoint through the following flow:

  1. An authenticated user launches a PHA from within SharePoint 2013.

  2. A context token is sent to the PHA, which contains a refresh token.

  3. The refresh token is used to request an access token from ACS.

  4. The access token is used as a bearer token in subsequent REST (or CSOM) calls to SharePoint by the PHA.

One of the most interesting aspects of the authentication and authorization flow for a PHA is that the app itself really has no direct authentication capability. Typically, the app is deployed with anonymous access and relies solely on the context token passed from SharePoint to secure user access. In a typical PHA built on MVC5, this verification is done using the SharePointContextFilter, which ensures a context token exists or the user is redirected back to SharePoint for authentication.

A similar check exists in an ASP.NET web forms app during the init event. If you remove the filter from MVC5 or comment-out the code in the ASP.NET web forms application, users can go directly to the app without authentication. Of course, there’s no way to get an access token under such circumstances, but it does highlight how easy it is to break the security flow if you don’t understand it well enough.

When an app gains access to SharePoint, rights are determined by the lesser of what is requested in the app manifest and what is assigned to the current user. Additionally, the PHA supports app-only permissions, which can ignore the permissions assigned to the current user. The key concept here is that SharePoint is managing the app rights. That is not the case for an MAA.

MAA Authorization

Because an MAA is always accessed directly and not launched from SharePoint, it authenticates the user against AAD when they request a page. Furthermore, because the MAA is not a SharePoint app, it does not store its rights in SharePoint like a PHA. Instead, rights for an MAA are granted within Azure through the AAD interface. In the Azure portal, an application can be granted Delegated Permissions, which lets the MAA act in SharePoint on behalf of the current user. The interface for granting these permissions is shown below.


Like the PHA, the MAA also has a Client Id and Client Secret, which can be used to get an access token from the STS. For an MAA, that request is made to AAD with the following flow:

  1. The application makes a login request to using the Client Id.

  2. A code is returned that can be used to get an access token and refresh token.

  3. The access token is used as a bearer token in subsequent REST calls to SharePoint by the MAA.

Comparing Approaches

Both the PHA and the MAA approach offer the ability to utilize the SharePoint APIs. However, the user experience is slightly different. The PHA must be launched from within SharePoint while the MAA is accessed directly. This means that the PHA approach is best for supporting information workers who are already inside SharePoint, but need the additional functionality provided by an app. The MAA, on the other hand, is best for scenarios where SharePoint is acting as a back-end to the application and not a primary user interface. It also seems that developers with lots of SharePoint knowledge are likely to gravitate to the PHA, while traditional web developers might be more comfortable with the MAA. While it may seem at first there are two drastically different models, they both use the same bearer authentication mechanism underneath and provide a consistent framework. So, if you haven’t tried both approaches yet, spin up a new project and give them a shot!

Topic: Development

Sign in with

Or register

  • Do Remote Event Recievers work with an MAA? I would guess no, as SPO has no way to authenticate to the RER service, right?
  • This is a great post, very helpful, thank you
  • As an Admin using an MAA you have no way to make sure that it e.g. only reads the data - a MAA will potentially have the full power of the logged in user. A PHA access can be limited on the other hand