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
Many of the people that read my blogs are "SharePoint" people. So you have seen many of my previous posts on building SharePoint Apps. Low trust, high trust, OAuth in O365, blah blah (old and boring stuff). SharePoint Apps were a great start to making Office apps run in predictable way using best practices in terms of user authentication (ie apps don't need passwords) and reliable API calls (REST and CSOM). But let's step back for a moment. In general, let's say our goal is to build an multi-purpose App (an app that spans multiple APIs and needs multiple client id and secrets). These apps are much more complex, as an example, let's talk about how one might build an app that:
- 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.
App Registries
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
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):
https://account.live.com/developers/applications/index
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:
SharePoint:
Yammer:
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.
Azure AD
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.
https://manage.windowsazure.com
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 t
hey 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
Google Apps registration is available here:
https://console.developers.google.com/project
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
Now let's talk about OAuth 2.0 flow support. If you haven't seen HelloJS well, you are missing out. It is an incredibly simple OAuth JavaScript library that allows you to do OAuth authorization in a very simple manner. As it is using JavaScript, it is a client side implementation. This means that Azure must support some type of cross origin scripting support (CORS) to get access tokens using simple token flows. If this is possible today, it isn't documented anywhere. As it stands right now, you need a server side component to broker the auth calls (WebAuthBroker pattern). Hopefully this changes in the future or becomes better documented.
Introducing Auth0.com
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.
Summary
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.
