One of the greatest strengths of the Microsoft collaboration platform, which now encompasses both SharePoint on-premises and Office 365 in the cloud, has always been its rich extensibility options. Customers who wish to enhance the platform with dynamic line-of-business solutions or organization-specific customizations have a rich set of APIs and remote interfaces to work with that provide a great deal of flexibility in designing engaging, user-centric applications. With the recent addition of Azure Web Applications, Microsoft has created yet another method for extending the cloud experience, presenting developers with a new set of application design choices.
It is important to understand the differences in scope and context between the two models before making a decision on which to use. Add-ins provide a contextual extensibility experience in which applications are deployed to specific content sites, activated by a site or tenant administrator, and accessed from the Quick Launch menu or Site Contents page within a team site with localized permissions. In contrast, Azure Web Applications are intended to be global across a tenancy: They are deployed by an Azure administrator, accessed from the App Launcher menu in the Suite Bar, and permissions are applied on a user or group basis. So the first decision developers must make when choosing a model is how their application will be deployed and accessed: Azure or Office 365? Global or local? Site-centric or user-centric?
Authorization and authentication must also be taken into account when determining which type of application to build. Office 365 Add-Ins are entirely dependent on the OAuth protocol for the exchange of tokens that grant access to content and services. Fundamentally, there is no true single sign-on experience in this model, as user and application permissions are derived from the context from which the application was accessed and the person who accessed it.
Azure Web Applications, on the other hand, integrate natively with Azure Active Directory. Users can log in directly to the application without first going through Office 365 if they desire and access resources based on permission levels assigned by the Azure administrator. It is also worth noting that Azure Web Applications, in addition to supporting single sign-on, support OAuth authorization flows and token exchange, making them more flexible overall than Add-Ins, which have no concept of user identity beyond their SharePoint user context.
One final consideration is the infrastructure required to run the application. Office 365 Add-Ins have two primary hosting methods: SharePoint hosted, in which the application runs entirely within the SharePoint framework with no external requirements; and Provider hosted, where the application can run on any Web server accessible by the user. Azure Web Applications follow the Provider-hosted model and can run anywhere except within the Office 365 infrastructure. This is an important design decision, especially if the developer is an ISV or third party who intends to sell his application in the Office store or Azure marketplace.
So which model is best suited for new application development? As always, that depends on the type, purpose and intended use of the application. The good news is that developers now have more options for creating solutions that satisfy a wide range of requirements, from contextual plug-ins to multi-tier applications with single sign-on, with the ability to enhance and extend the Office 365 platform well beyond what is available out of the box.
Eric Shupps is a SharePoint Server MVP, and the founder and president of BinaryWave, a global provider of SharePoint managed services. Eric has worked with SharePoint products and technologies since 2001 as a consultant, administrator, architect, developer and trainer.