App scope and permission
When a remote request is made into SharePoint by an app component, one of three policies is used to determine what access that request will have.
The first policy is the user-only policy. In this case, authorization decisions are made based only on the identity of the authenticated user. Essentially, this is the same security that existed in previous versions of SharePoint and when using SharePoint 2013 outside of the context of an app. The permissions within SharePoint’s sites, lists, and libraries are compared to the user’s identity, including any security groups they are a member of, to determine the access to be granted.
The most common policy used by SharePoint apps is the user+app policy. This policy takes into account both the user’s identity and the app’s identity. The permissions granted to an app are different from those granted to a user. Whereas a user might be given read access to a certain document or list, the app would need to have the more generic right to read data from lists before it would be allowed to complete the operation. The user+app policy is the policy normally used when an app component makes a request back into SharePoint.
The final authorization policy is the app-only policy. This type of policy is used when only the permissions of the app are relevant. Because the user’s permissions are not being checked, this should be considered a form of elevated permissions. As a result, only certain users can install an app that requires the use of the app-only policy and, even then, it should be used with care. The intent of this policy is to allow the following types of requests:
Some requests are made without user interaction, such as some workflow actions and remove event handler calls. Since there is no interactive user, there is no user identity to pass.
An app that needs to perform an action on behalf of the application owner instead of the current user would use this policy as a form of elevated privilege to perform these tasks.
The app-only policy must be enabled explicitly by the site administrator when installing the app. Otherwise, the app will not be allowed to make such calls since they could be used to circumvent SharePoint’s permissions.
The user installing the app is presented with a listing of these permissions during installation and must approve their use by the app. Without this explicit granting of app permissions, the app cannot be installed. Of course, users cannot install an app that requires permissions they do not have themselves, since they would be unable to grant those permissions to the app.
The last piece of information to be provided is optional. The properties of a permission request can be used to further limit the scope of the request. The types of properties available depend on what scope is being used. The property shown in Listing 1-2 specifies that the request applies only to lists based on template number 101, which is any document library.
All of the scopes listed above use rights of READ, WRITE, MANAGE, and FULL CONTROL, except for search. The search scope only has one option (QueryAsUserIgnoreAppPrincipal) that permits the app to perform searches. Additional scopes apply to specific services within SharePoint 2013, such as BCS, taxonomy, and social features.