User and App Identity in SharePoint 2013 Apps

According to MSDN (, apps in SharePoint can operate using one of 3 authorization policies; they are:

  1. User-Only policy
  2. User + App policy
  3. App-Only policy

1. User-Only policy

This is the default and apparently has nothing specific about whether you are developing an app or not. As described in MSDN, an example of when this policy is enforced is when the user is accessing resources directly without using the app. The remaining two are more interesting.

2. User + App Policy

This policy helps when the requirement is to allow an operation by the app to succeed in the host web if both the app and the current user who is running the app have the proper rights. Whenever we perform an operation using this configuration, you will get a result similar to the following where an item is created by the app on behalf of the USER.


3. App-Only Policy

This policy helps when the requirements are to allow an operation by the app to succeed in the host web if the app itself has the proper rights to do so irrespective of whether the current user has rights to perform that operation or not. Although there can be various use-cases for this, an obvious choice for me would be to handle the anonymous update scenario. This opens up new authorization scenarios as admins may only need to provide access to the app and no particular user. Only the user who installs the app (admin usually) need to possess the rights. The following figure shows another item in the same list which only shows created by the app.


One important aspect to note here is that the App-Only policy will only work for cloud-hosted apps where you are able to run custom .NET code to handle OAuth authentication tokens. SharePoint-hosted apps or self-hosted apps cannot run .NET code so they cannot benefit from this ability.

Now let us look into the code which enables all this. Fortunately, Microsoft has included a TokenHelper.cs file in its preconfigured VS 2012 templates for creating SharePoint apps.

TokenHelper.GetAccessToken will provide us the App+User token whereas TokenHelper.GetAppOnlyAccessToken will provide us the App-Only token. So if you want to create a list item in the host web list using an App+User token then make sure you use the token returned from the GetAccessToken call in your Client Object Model or REST calls. Similarly, if you want to create a list item in the host web using an App-Only token then make sure you use the token returned from GetAppOnlyAccessToken. This is all there is to it, however, there is one very important configuration to note, also explicitly mentioned here, which is to make sure that your app explicitly asks for Allowing the App-Only policy by setting the following attribute in the app manifest.


Without setting this permission you will get "Access Denied" errors for ur CSOM or REST calls.

Interestingly, allowing this attribute prompts the user to "Let it share its permissions with other users."


Whereas an app deployed without this attribute does not have this message.


I think this authorization model and the simplicity with which it can be used will make it much easier for the developers to handle authorization issues in their SharePoint 2013 apps.