Introduction to SharePoint 2013 Apps

What is an app for SharePoint?
In simple description, an app for SharePoint is a web application that is registered with SharePoint using an app manifest. The app manifest defines the properties of the app like where is the app hosted, what is the start location of the app, what permissions/scopes are requested etc. The following code is a very simple app manifest that basically tells SharePoint to register the app and invoke a remote page when the app starts.

<?xml version="1.0" encoding="utf-8" ?>
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest (http://schemas.microsoft.com/sharepoint/2012/app/manifest)"
    ProductID="{90A1A0AE-4B83-4DD6-874A-76C1AA23C1FD}"
    Version="1.0.0.0"
    SharePointMinVersion="15.0.0.0"
    Name="BookStore">
  <Properties>
    <Title>Share Books</Title>
       <StartPage>https://localhost:8082/bookshome.aspx/?{StandardTokens}</StartPage>
  </Properties>
  <AppPrincipal>
    <RemoteWebApplication ClientId="A01DA985-DFB9-42F9-B20D-013FA60C587B" />
  </AppPrincipal>
</App>

What are the different modes of Application deployments? 
SharePoint-hosted apps: Here the app is hosted in SharePoint itself. The only way it can communicate with the SharePoint is through CSOM/REST (Javascript). No server side code is allowed. When you install this kind of app, SharePoint creates a new website called the app web. 

1. Provider-hosted apps: Here the app is hosted by a provider. Optionally, it can provision a new website called the app web in SharePoint. Provider is responsibile for the isolation of the tenants. CSOM/REST can be used to communicate with the SharePoint apps. 
2. Auto-hosted apps: Here the Web and SQL Azure components required for the app are provisioned by Windows Azure. Optionally, it can provision a new website called the app web in SharePoint. Here multitanancy is supported by Windows Azure itself. CSOM/REST can be used to communicate with the SharePoint apps. 

Authentication options in apps for SharePoint
When the app is running within the SharePoint, then the app is intrisically authenticated. For the apps on the cloud, to integrate with SharePoint there are two ways:
* Using client-side code along with the cross-domain library.
* Using server-side code along with OAuth.

App permissions in SharePoint 2013
An app for SharePoint requests the permissions that it needs during installation from the user who is installing it. The developer of an app must request, through the app manifest file, the permissions that the particular app needs to be able to run. The user who installs should have the required permissions first, then app must either be granted all the requested permissions or should not be granted any permissions.


Application Permissions
* The permission requests specify both the rights that an app needs and the scope at which it needs the rights. These permissions are requested as part of the app definition through the node .
* Permission request scopes indicate the location in the SharePoint hierarchy where a permission request applies.
* An app for SharePoint has its own identity and is associated with a security principal, called an app principal. Like users and groups, an app principal has certain permissions and rights. The app principal has full control rights to the app web so it only needs to request permissions to SharePoint resources in the host web or other locations outside the app web.

If an app is granted permission to one of the scopes, the permission applies to all children of the scope. Some of the basic scopes are as follows:
Scope URI  :  Description
* http://sharepoint/content/sitecollection  :  The permission request scope URI to the site collection where the app is installed. 
* http://sharepoint/content/sitecollection/web  :  The permission request scope URI to the website where the app is installed. 
* http://sharepoint/content/sitecollection/web/list  :  The permission request scope URI to the list where the app is installed. 
* http://sharepoint/content/tenant  :  The permission request scope URI to the tenancy where the app is installed.

For each scope, an app can have the following rights:
Read, Write, Manage, FullControl
These corresponds to the default permission set of SharePoint Reader, Contribute, Designer & Full Control. Unlike SharePoint, these app permissions cannot be customized.

You could filter the lists on which the permission set is valid, by using the BaseTemplateId property.

<AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list" Right="Write">
    <Property Name="BaseTemplateId" Value="101"/>
</AppPermissionRequest>

In SharePoint 2013, end users have four different opportunities to manage app permissions:
* During app installation
* By using explicit permissions management
* By using an end-user consent UI
* During app removal  

App authorization policies
This defines the target (User/App) on which the permission set is validated on for the requested operation. 
1. User and app policy - Content DB authorization checks are made on both User and the App for sufficient permissions to perform the operation. 
2. App-only policy - Only the App is validated for sufficient permissions.  
3. User-only policy - Only the User is validated for sufficient permissions.  


References: 
SharePoint 2013 Apps Overview: http://msdn.microsoft.com/en-us/library/sharepoint/fp179930(v=office.15)
Developing Apps for SharePoint 2013 : http://msdn.microsoft.com/en-us/library/office/apps/jj220038(v=office.15).aspx