In SharePoint 2013 Apps, the authorization is handled by a 2 part mechanism. Along with the current user's permissions, the app permissions are also taken into account. User permissions and app permissions are two separate entities which dictate whether an app is allowed to perform a certain action.
When you build an app, you can specify that what all permissions are going to be required for the app to run successfully. You have to specify this in the App Manifest under the Permissions tab.
(Click Image to Zoom)
![]()
When a user installs an app, he can only grant permissions to the app up to the level which he has. So if a user has "Read" permissions on a list, he cannot grant the app "Full Control" on the same list.
![]()
There are basically 3 types of app authorizations or authorization policies in SharePoint 2013.
1) User Only Policy: In this policy, only the user permissions are taken into account. App permissions are ignored. It is checked whether the user has the permissions to perform the action and if yes, then he/she is allowed to perform the action.
2) App + User Policy: The user as well as the app permissions are taken into account. This is an AND operation. If both the user and the app have the permission to perform the action,only then the action is allowed.
3) App Only Policy: Only the permissions granted to the app are taken into account. User permissions are ignored. So even if the current user accessing the app does not have appropriate permission, the action is allowed provided the app has the permission to do so.
The App Only policy works by using a separate OAuth token which runs under the user "SHAREPOINT/App" much like SPSecurity.RunWithElevatedPriviledges() runs under the "SHAREPOINT\System" user (app pool account) in the Server Object Model.
To enable the App Only policy in your app, you have to add the "AllowAppOnlyPolicy" attribute to your "AppPermissions" element in the App Manifest:
Enough chit chat, lets see how we can actually utilize the App Only policy to elevate user permissions. I have written the following code in the code behind of the Default.aspx of an Auto-Hosted App:
As you can see, the ClientContext which is opened with the appOnlyAccessToken will run with the identity of the SHAREPOINT\App account. This is a very good practice to remember even when using RunWithElevatedPreviledges in the Server Object Model. You can switch on/switch off database calls with app only token. This means that if you need to make only one operation with the elevated token, then you can do that and get back to using the current user's token in one action.
When you build an app, you can specify that what all permissions are going to be required for the app to run successfully. You have to specify this in the App Manifest under the Permissions tab.
(Click Image to Zoom)
When a user installs an app, he can only grant permissions to the app up to the level which he has. So if a user has "Read" permissions on a list, he cannot grant the app "Full Control" on the same list.
There are basically 3 types of app authorizations or authorization policies in SharePoint 2013.
1) User Only Policy: In this policy, only the user permissions are taken into account. App permissions are ignored. It is checked whether the user has the permissions to perform the action and if yes, then he/she is allowed to perform the action.
2) App + User Policy: The user as well as the app permissions are taken into account. This is an AND operation. If both the user and the app have the permission to perform the action,only then the action is allowed.
3) App Only Policy: Only the permissions granted to the app are taken into account. User permissions are ignored. So even if the current user accessing the app does not have appropriate permission, the action is allowed provided the app has the permission to do so.
The App Only policy works by using a separate OAuth token which runs under the user "SHAREPOINT/App" much like SPSecurity.RunWithElevatedPriviledges() runs under the "SHAREPOINT\System" user (app pool account) in the Server Object Model.
Since OAuth is required to generate the app token, the App-Only policy can only be used in the Auto-hosted and Provider-Hosted apps. SharePoint-Hosted apps cannot use the app only policy.
To enable the App Only policy in your app, you have to add the "AllowAppOnlyPolicy" attribute to your "AppPermissions" element in the App Manifest:
Note: Although you can add this attribute to the App Manifest of the SharePoint-Hosted apps, it will be ignored as the App Only policy is not supported in SharePoint hosted apps.
Enough chit chat, lets see how we can actually utilize the App Only policy to elevate user permissions. I have written the following code in the code behind of the Default.aspx of an Auto-Hosted App:
As you can see, the ClientContext which is opened with the appOnlyAccessToken will run with the identity of the SHAREPOINT\App account. This is a very good practice to remember even when using RunWithElevatedPreviledges in the Server Object Model. You can switch on/switch off database calls with app only token. This means that if you need to make only one operation with the elevated token, then you can do that and get back to using the current user's token in one action.