In my last post, I discussed the introduction into SharePoint App development and why I think it’s important for SharePoint & Office 365 going forward. Any technology stack can hold a fair amount of criticism and while some may not fully accept the SharePoint App model right now, remember that SharePoint is a rapidly expanding framework and I think we’ll start to see advancements in the “App Model” going forward.
In this post, I’d like to discuss the different types of SharePoint apps we can build for SharePoint 2013 and Office 365. As mentioned previously, Apps open up our world to a place where beautiful, flexible and platform agnostic applications can be developed to solve any business need within SharePoint. When building a “SharePoint App” we have two options to choose from – SharePoint hosted apps or Provider hosted apps. Let’s dive deeper into what this means…
SharePoint-Hosted Apps
SharePoint-hosted apps are the most simplistic form of apps we can build for SharePoint. All components are hosted on-premises or in Office 365. These apps are built using JavaScript & HTML. You will have the ability to reuse common SharePoint components such as lists and Web Parts but just know you are unable to write any server-side code when building a SharePoint-hosted app. You may ask “Well how complex is the security model and what kind of security trimming will I (a developer) have to build out when creating my SharePoint-hosted app?” Well that is quite simple, your app has only the privileges of the signed-in user, which means security trimming is a breeze using standard SharePoint permissions! The downside for some however is, you have no ability to run with an elevated permission set like you could in farm solutions.
Provider-Hosted Apps
Provider-hosted apps takes abstraction to another level. You can probably guess from the name, but a provider-hosted app is where components are deployed and hosted outside your SharePoint farm. You have the flexibility to determine where you want these apps to be hosted whether on-premises, on an application server, or running within Azure. The benefit to create a provider-hosted app is that it allows you to use any technology stack you wish! You can choose to develop both client and server side code in any language or framework of your choosing. In the past we’ve always had to develop solutions using .NET and JavaScript, but now we are open to using PHP, Ruby or whatever flavor you would prefer to write in! That is all fine and dandy but how do we authenticate and authorize users if the code itself is running outside of SharePoint? With these type of apps, you must use one of three types of authorization systems.
Low-Trust
A provider hosted app can register with Azure’s Access Control Service (ACS) which provides a token for the app which allows the app to access resources within a SharePoint farm. ACS is the trusted issuer in OAuth 2.0. These low-trust systems are intended for apps where the provider is in the cloud.
image source: http://devproconnections.com/net-framework/access-control-cloud-windows-azure-appfabrics-acs
High-Trust
Unlike low-trust, high-trust authorization is achieved using digital certifications from your provider to the SharePoint environment. This is only intended for on-premises environments and does not work in Office 365.
Cross-Domain Library
If your app is built using primarily JavaScript or any JavaScript frameworks you can use SharePoint’s cross-domain library to achieve authentication and authorization. There may be a scenario where you have an Office 365 installation but due to restrictions in your corporate environment, your firewall prevents you from accessing resources using low-trust, you can supplement this issue by using Cross-Domain Library.
Subcribe to be the first to read SharePoint App Model: Part 3
Share
