Let's talk apps for a moment. A couple of questions for you:
- If you were to build a single purpose app, where would you do it, how would you do it…why would you do it?
- If you were to build a multi-purpose app, where would you do it, how would you do it…why would you do it?
If you are stuck in single purpose, Single Page App (SPA) land, then you are quite a few months behind where you should be. You should be thinking, if I am going to build an app, where will I get the most bang for my buck? If you are a customer, are you going to ask a consulting partner to build you an app in the future? If so, do you understand what might happen in the future that will cause you to refactor (rebuild) your app?
Do you understand the differences between application registries such that you know what might happen in the future or how you should architect your apps?
A Scenario to Think About
- Makes a call to Visual Studio online to get project data that populates Project Server Online with tasks. The app then adds to your O365 calendar items assigned to you based on project tasks. In addition, the app will post messages to Yammer throughout the entire process. Additionally, it needs to post various data points by taking snapshots of project report data to a customer's OneNote.com notebook.
This scenario, which I have no doubt many of you will think is "cool" or "I want that", will not be well understood from the sheer amount of effort this will take. You won't fully recognize the plethora of APIs and App registries of which you would need to create and have target user's authorize in order for your multi-purpose application to work.
So what do I mean when I say "App Registry"? As the title of the post eludes too, there are several of them you might be interested in:
- Google Apps
- Azure Active Directory Apps
- SharePoint Apps
- LiveId Apps
- Yammer Apps
- Facebook, twitter…on and on…
All of these registries utilize OAuth 2.0 as their underlying auth architecture. When you create an app in a registry, they are going to issue you a client Id and client secret. In the scenario above, you will see that you will have at least five different apps. In your multi-purpose app, you will need to manage the auth process with all the client ids and secrets in that app. This is incredibly painful to manage without using some kind of library in the middle (there are several, take your pick with each being targeted at some platform, we need a platform agnostic approach, see later in this post). In the end, the goal is to get an "Access Token". Once you have acquired this token, you can make API calls from your app using the "Authorization" header in the HTTP request. It is this access token that defines the scopes at which your application with be authorized (such as creating an email, creating a one note page, creating a file in your OneDrive [either consumer or business]).
Since many of you are familiar with the concept of SharePoint and slightly less familiar with Yammer Apps. Neither of these I will talk much in this post. But let's do take a look at Live ID vs Azure AD vs Google. Live ID is what has traditionally been considered the "consumer" authorization platform. We use it to login to HotmailOutlook.com, our msdn accounts, our OneDrive consumer and OneNote consumer as just a few examples. Until last week (5/21/2014), Visual Studio Online was also using Live ID (it now supports Azure ADOrganization Accounts but you currently have to create a *new* account and can't move your old one, hopefully that will change).
LiveID has been around for a while and there are many apps written to support consumer services. If you wanted to create a LiveID app, you can do it here (note you must have a Live ID account to create one):
Once you register an app, you will see it in the portal:
Scopes for apps include the following:
Just for kicks, here is SharePoint and Yammer registries screen shots:
As a side note, SharePoint and Yammer Apps cannot make calls to O365 APIs, nor can they make calls to LiveId APIs such as OneNote and OneDrive.
Enter Azure Active Directory. With the huge success of O365, Azure AD is being used as the organizational account backing (in the absence of federated auth) and with the new O365 APIs, as the application registry. To register an application, you must create an app in the Azure management portal. By default, your app is only visible to your organization, but can be made to be utilized by external organizations.
As it stands right now, Azure AD only has a small set of apps that are using it (aside from custom organizational ones) which is commonly referred to as the Consent Framework:
- Azure Management
- Azure Active Directory
- Office 365 Exchange Online
- Office 365 SharePoint Online
These are shown in the following screenshot (with the "scopes" that each exposes):
SharePoint Permissions versus Azure Permissions
One of the big gaps between writing an Azure App and a SharePoint app is the level of permission granularity. Take a look at the Azure permissions for SharePoint Online in the above screen shot, now look at the available permissions for a SharePoint App in the next screen shot. What a major gap in permission granularity!:
If we were to contrast these to the Google Apps portal, things start to get interesting in terms of what the future will hold for Azure AD Apps. The Azure UI is really primitive in terms of permissions assignment (imagine if you had 100 permissions for an app). Additionally, a drop down won't cut it if they move to as many online supported services as Google has (which is the next registry I explore). And just to add insult to injury, this error is one of the most annoying EVER:
Google Apps registration is available here:
Here is a screen shot of the Google Apps page:
Google vs Azure – "One client id and secret to rule them all"
As compared to Microsoft, hopefully you were able to surmise that Google utilizes a single app registry (with a single client id and secret, with a much more advanced and comprehensive Consent Framework and UI). So what does this ultimately mean for Azure AD? If you look at Azure AD, it is in its very early stages (V0.8 maybe?). Only a few apps are supported when it comes to the Microsoft set of online services. As compared to Google, they have a lot of work to do. Each team within Microsoft must make the decision to adopt Azure Active Directory as its future authorization platform in order for us to take advantage of a "single client id, single client secret" as we can do today with Google. Visual Studio Online made a step towards making this a reality last week.
OAuth 2.0 flows and HelloJS
So let's go back to the original scenario. If the goal is to simply get an access token and similarly, make an API call to get a JSON response back, should we really care about any of the details of that process times five (LiveId, AzureAD, SharePoint, Yammer, Google, et all)? Are you reinventing the wheel over and over again each time you create a new app in any of those registries? The answer is yes. Enter Auth0.com. Auth0 stands to change the way we build our multipurpose apps. You can get a sample of how Iwe use Auth0 on our SanSpug.org site by attempting to login using any number of OAuth 2.0 credentials (facebook, twitter, etc). In addition, you can abstract away the API calls for target services such that you simply need to get the responses back and perform your business logic.
Auth0.com is the ultimate Web Auth Broker servicepattern! I highly suggest that you take a look at Auth0 and how you can utilize it in your future app design.
Hopefully you now have enough of a background of information to make some education decisions (such as wait for a few more months?) in terms of what you might want to consider moving forward in your app design and architecture strategy. I personally see Azure AD winning out over LiveID. What this means in the long term with respect to services such as MSDN and the various other business services (MSInvoice, et all) hosted by Microsoft for vendor interaction (of which use LiveID today) is really foggy and not well defined. A lot of these thoughts I have already conveyed to the various Microsoft teams that should be thinking about the above concepts. The ball is in various Microsoft's exec's courts to make a high level decision to do the migration towards catching up with Google and deciding that consumer is consumer (LiveID) and business is business (AzureAD). If they draw that line, you will see migrations away from Live ID happening left and right.