Apache Cordova, Apache Ripple, Visual Studio 2013 and O365 APIs

"Mobile first" has become a common theme these days and building code and applications that you can write once and deploy to multiple target platforms is a key to achieving reach and use for your backend platform.  With the O365 APIs being release a few weeks ago, you can now do REST development against O365 exchange services (Mail, Contacts and Calendar, however, no Tasks yet).  A lot of focus has been on putting out samples for the various mobile platforms (Windows Phone and Android as the top two).  That being said, let's take a look at these Android examples and then the new Apache Cordova project templates. 


The Android SDKs that you can download here need some serious help in order to get them loaded into a Java IDE (such as Eclipse Kepler).  For example, not only do you need the Active Directory library, you also need several Google SDKs (yeah, I said Google).  In order to get all the examples working, you need to download the following:

Once you have all these, you can extract the O365 SDK and you will notice several projects that you can import into Eclipse (you will notice that all of them have errors, this is because you need to add the referenced JAR files to the project build path):


Each project will need the "com.microsoft.adal", "office365-base-sdk", json-2.2.4" and "guava-16.0.1" JARs.  Once you have these added, you will notice that all the projects now show no errors.  You are now free to select a project and run it. The first app is called the "Asset Management" app:


Opening the application allows you to start configuring it:

The authentication options can be of three types:

Azure Active Directory (AAD) is the OAuth method. Selecting it will allow you to utilize redirection to O365 login page and then back to your application.  Once you have authenticated, you can click the "Show Cars" button:

It simply makes a call to a SharePoint picture library called "Cars" (that you have to create and add items too) to show you the picture of the car and its description:

In addition, there is a "File Discovery" application.  This can be configured by modifying the "Constants.java" file (which is a common thing across the apps) by adding your client id and secret.  Once you have updated the files, running the app will show the following icon:

Once open, you will see that it queries the discovery service and shows all your services (via the Discovery API):

Clicking on the Files service will show you your OneDrive for Business Files:

You may find that you keep getting an exception around the dialog.dismiss method.   This is a bug in the code, all you have to do is wrap it in a try catch block and the code will run ok.

There is also a mail app (but it doesn't have a .project file so it won't import as a project).  Unfortunately I was never able to get it to work because it kept throwing memory errors, but supposedly you can also get it to show you your mail. You will also need a couple of extra JAR files to get it to compile:

Apache Cordova:

Not into building platform specific Apps like the Android ones above?  That's where the Apache Cordova platform comes into play!  If you do a quick Google search, you will find this site:


This site simply describes itself as "A platform for building native mobile applications using HTML, CSS and JavaScript".  Basically what that means is that it is a translation middleware of common web standard elements as common inputs and then transform your code to a target such as Android or Windows Phone.  The neat part is that Apache Cordova is now integrated into Visual Studio 2013 Update 2.  You can download the Apache Cordova project extension here:


This will give you the ability to create Hybrid Apps:

 Once you have created a Hybrid App, you will see the following in your Solution Explorer:

In Visual Studio, you will have a set of target devices and also the ability to specific your debug target:


Notice here, the "Ripple" debugging target.  Before you start debugging, you can modify the supported features of the target device via the App Manifest's "Plugins" tab:


 Now this is where things get interesting.  You can right-click the project and select "Add->Connected Service".  From here you can add either "Windows Azure Mobile" or "Office 365" services. 


The view is similar to if you were doing an MVC or Web Application Project, but the output is VERY different.  What you will notice is several folders and JS files are added:


The above "settings.js" does some initialization of the O365 SDK. The remainder of the files have some pretty powerful code in it that all but builds your application logic!


Once you have all of these files in your project, you have to add them to your "index.html" page:

    <p>Hello, your application is

    <!-- Cordova reference, this is
added to your app when it's built. -->
    <script src="cordova.js"></script>

    <!-- cjg699 references -->
    <script src="./services/mobile services/cjg699/service.js"></script>

    <script src="scripts/jquery-2.1.1.js"></script>
    <script src="services/office365/settings.js"></script>
    <script src="scripts/aadgraph.js"></script>
    <script src="scripts/exchange.js"></script>   
    <script src="scripts/o365adal.js"></script>
    <script src="scripts/utility.js"></script>   
    <script src="scripts/index.js"></script>
    <script src="scripts/o365.js"></script>
    <input type="button"
id="btnGetEvents" name="btnGetEvents"
onclick="GetEvents();" value="Get Events" />
    <br />
    <br />
    <div id="Events">

Once that is done, you can add your own O365.js file with your logic.  In this case, I am simply making a call to get the events:

GetEvents() {
    var authContext = new
    .then((function (token) {

        // authentication succeeded
        var client = new Exchange.Client('https://outlook.office365.com/ews/odata',

        .then(function (events) {
            // get currentPage of
calendar events
            var myevents =


            for (i = 0; i <
myevents.length; i++)
$("#Events").append("Subject: " +

        }, function (reason) {
    }).bind(this), function (reason) {


 Pressing "F5", Google Chrome will start with the Ripple emulator:


You can now click on the "Get Events" button which will attempt to execute the code, but first direct you to provide consent:

Clicking on "Get Events", you will see your mail:


One important note, the JavaScript code will cache your access token.  If you didn't get your permissions setup properly, then you'll have a bad token cached.  You will need to call the "SignOut" method to clear the CacheManager and the bad token as they don't expose the CacheManager directly.

If you wanted to test on Android, you would simply change the drop down target and press "F5" again.  It would then attempt to start the current Android SDK Emulator and upload the APK file, you would see exactly the same UI and button and the same results!

Unfortunately, at the moment, the JavaScript API for O365 is only provided in the Hybrid Apps project and is not really compatible with the other project types (such as MVC).  Apache Cordova, the Ripple emulator and project templates such as Hybrid and Cloud Business Apps are the future of application development!

Azure Access Control Services (ACS) is dead

I recently went through the exciting process of setting up our SanSpug.org site to support various authentication mechanisms (LiveID, Google, Federated Auth, etc).  I started off using Azure Access Control Services (ACS) because I thought it had everything I could ever want in a login aggregation platform.  However, I soon realized that it just wasn't able to meet the simple needs of a small SharePoint User Group.  And now that I know it can't meet those needs, I doubt it really meets the needs of large organizations either. 

A bit about ACS

To be fair,  ACS was the first of its kind.  I remember when it was first released, it was sooooo cool.  It really was.  I built some cool labs off of it (the old UI), then the UI "disappeared" (at least, the link was gone from Azure at one point), only to reappear again in the latest incarnations.  ACS isn't a part of the main Azure portal.  It has its own interface, which has confused me to this day being that all the other services are moving into the current portal.  Here's a screen shot of the two:


Why they are separate probably has to do with (put some random excuse here, but likely because of "legacy" configurations). It would make much more sense that Azure added ACS as its own separate application in the Azure Portal. 

So what can we do with ACS?  If you are familiar with ADFS, then you get the point.  I can created "Identity Providers", "Relaying party applications" and claims rules between the two.  The latter being one of the strengths of ACS (Quick history lesson, ADFS 1.0 was a real piece of junk, that left only one option, that option being ACS. It could do all the things that ADFS 2.0 was about to do).  So what kinds of identity providers can we add?  Well, here they are:


Hmm, interesting.  So they have preconfigured providers for LiveID, Google and Yahoo.  Fair enough, those don't actually need an application (client id and client secret) created for them.  But "Facebook".  Ummm, that one needs an app created for it to do federated auth.  Ok, let's do it.  Added a facebook app used to be fairly easy back in the day, now the UI sucks.  And the process to get a simple "App Stub" created requires a canvas page?  Whatever.  Fail on facebook's part.  Ok, back to ACS.  So they are allowing us to do federated auth to OAuth providers.  Ok.  So how do I add others?  Like Twitter?  Maybe Yammer?  Oh…YOU CAN'T!  But you can do WS-Federation all day long.  Boring.  Oh, did I mention the Google one doesn't work anymore?  Yeah, Google seems to have disabled the interface that ACS was using.

Ok, so ACS is dead "to me".  So what do I do now?  Do I build my own?  Ugg, that means I need to register an app in EVERY possible OAuth provider on the planet.  Similar hoops to jump through (approve the app, screen shots, canvas page, terms…ugg, no thank you). 

Let's do some research, maybe someone built a better ACS?  Maybe someone did all that work to register an app EVERYWHERE? After a few google searches, some tweets…I find….Auth0.com. 

Auth0 is the ACS killer.  I have no doubt that after the right people at Microsoft see what they have built, Auth0 will be picked up in a M&A transaction.  I'm going to tell the guys to hold out and get 4-5 offers and bid the price up.  I have no doubt, they will go for $100Ms in a liquidity event.  So why are they so cool?  Because you can add ANYTHING!  Check this $^&%^% out!  Database, Social and Enterprise:

Database (think ASPNETDB – this is a biggy for SP2015 by they way):


Social (oh right…ACS gives us…Facebook…totally lame):



Wait…do you see the one at the bottom?  Yeah…that's SharePoint Apps for on-premises (courtesy of Chris Beckett consulting services).  Oh…do you see the O365 and Windows Azure AD one?  Oh yeah…that's Azure AD Apps…umm, so why are you using ACS again?

Telemetry and Metrics

Are you freaking kidding me?  ACS would never have thought this up.  You get telemetry on when and how your users are logging in:


The logs are also pretty sweet:


You see the profile JSON response in the Logs that contains the Access Token (if provided) so if you need to debug something, you have everything you need!


Wait…it gets better (but maybe a bit confusing for you that haven't been doing this stuff for a while).  In addition to allowing your Apps access to all these federated OAuth platforms, it itself is an App registry.  You can create your App in the Auth0 interface, which is then exposed as a WS-Federation end point!!!  Holy $%&^&$^!  Forced to use ACS, but you think it sucks like I do?  Hey…add your Auth0 WS-Federation endpoint, and just like one of those "I saw it on TV adds", "Set it and forget it!":



Oh baby…if they weren't already ahead of the competition.  This is the future.  Forget about all those APIs you have to write to and learn.  Why bother with the auth parts?  All you need is to call the API and get that JSON response back.  Here's what they support:



Do you have some ACS rules?  Yeah, they support that too…what they don't have is an ACS rule importer.  That would be so slick. Easily migrate from crappy old ACS, to shiny new Auth0:


Custom Emails:

Just to add insult to injury…woah…custom emails…custom whatever!  When someone hits your fed auth endpoint…send em an email based off the claims!


Is ACS Dead?  Yeah, to me it is.  To the masses that didn't know any better, consider yourself educated.  As the word spreads, I'm sure there will be a mass ACS exodus very soon!


OneDrive vs OneDrive and OneNote vs OneNote – Why the disconnect?

So you think you know OneDrive eh?  If you were knowledgeable, you'd ask, which of the three?  Maybe you knew that, maybe you didn't.  But I'd venture to say that many don't really understand the programmatic aspects between the various versions.  Additionaly, since I'm going to talk about APIs, I might as well throw the OneNote API into the mix.  One Drive exists in three states:

  • OneDrive for business (the version that runs in your O365 tenant)
  • OneDrive Pro (the version that runs in your on-premises environment)
  • OneDrive Consumer (the version that runs in your LiveID environment) 

OneDrive for business and OneDrive Pro are simply SharePoint document libraries that exist in your My Site.  The APIs for gain access to these are as "simple" as making basic document library API calls for any SharePoint document library.  These SharePoint file APIs are documented here:


Notice that you must specify the url of the site (in this case it is your My Site url) in order to give context to API calls.  For a typical O365 instance, this looks like:


All REST calls and CSOM will need to be instantiated with this url. Now consider folder nagivation.  In SharePoint, you must use the "GetFolderByServerRelativeUrl" method on the web object. An example of this call looks like this:

https://acs579-my.sharepoint.com/personal/givens_acs579_onmicrosoft_com/_api/web/GetFolderByServerRelativeUrl('/personal/givens_acs579_onmicrosoft_com/Shared Documents')

Umm…does anyone else think this is a super long and incredibly dumb way of getting to a file folder?  Yeah, thought so.  Let's take a look at a typical OneDrive consumer API call, which are documented here:


As an example, to get your current one drive folder, one simply has to do a GET to:

https://apis.live.net/v5.0/me/skydrive (yes it is still called "skydrive")

Wait, do you see that?  Instead of "https://acs579-my.sharepoint.com/personal/givens_acs579_onmicrosoft_com/_api/web/GetFolderByServerRelativeUrl('/personal/givens_acs579_onmicrosoft_com/Shared
" it is "me".  Woah, what a concept. 

Now let's look at getting a file or posting a file.  Each file and folder has an id.  To get a folder, you simply do something like:

GET https://apis.live.net/v5.0/file.a6b2a7e8f2515e5e.A6B2A7E8F2515E5E!114
GET https://apis.live.net/v5.0/folder.a6b2a7e8f2515e5e.A6B2A7E8F2515E5E!114

Instead of…oh nevermind…its waaaay tooo long to copy and paste.

The implementation of file operations in SharePoint is horrendous and needs a total overhaul.

Now, let's take a look at OneNote.  In SharePoint, every site can have a OneNote notebook.  This notebook is rendered and edited using Office Web Apps and the OneNote.ashx handler.  Many of the features you have come to love work using the browser, but alas, we have zero programmatic capabilities. In contrast, the OneNote for consumer has a massively beautiful API to it as you can see here:


Wow, the ability to create and post to pages using a super simple HTTP REST API.  The OneNote endpoint is simply:


They are putting massive dev time into this API, but I'm afraid we won't be seeing it anytime soon in O365 or on-premises.  Check out the list of features coming via the OneNote blog (that's pretty amazing set of upcoming features):


What should you do?

Vote for the OneDrive implementation of "me" here in UserVoice:


Vote for the migration of the OneNote APIs here in UserVoice:


Additionally, if you are an MVP:

Make sure that you express your extreme disappointment when they send out emails saying O365, yet talk about LiveID consumer features.  It is extremely disrespectful to waste our time like that.

Workflow Manager: The dispatcher failure rate has reached 11%

There are only a couple of posts on this across the web, none of which have any replies to them.  This is because this issue relates to any number of failures that can occur with the Workflow Manager service. 

One such error is when you attempt to send a DynamicValue as the request header to an HttpSend Activity.  If any of the headers have a significantly large string to them, you will cause a buffer overflow in the Workflow Manager Service. 

In Workflow Manager 1.0 RTM and service bus 1.0 RTM, this will lead to an error reporting service to consume the remaining memory on your application server and thereby rendering that app server useless.  In the Workflow Manager 1.0 Refresh and Service Bus 1.1 versions, the error simply kills the Workflow Manager service over and and over again.

Distributed Cache cacheHostInfo is null

There are several blog posts on this across the web, many will fix your issue, however, you may find that in some cases, none of them work for you. One such issue is if the configuration file of the Dist Cache has your machine registered, yet it cannot any details about that machine in SharePoint, you will get this error.  Even if you run all those wonderful SharePoint cmdlets.  The fix is to export the configuration file, remove the offending server, then upload the configuration file.  Then your SharePoint cmdlets will work:

  1. Export-CacheClusterConfig c: empfile.txt
  2. Remove the offending server
  3. Import-CacheClusterConfig c: empfile.txt
  4. Run the appropriate cmds to add it back

Here is all the scripts I have compiled that will help you to solve any issue you may come across:

  Get-AFCacheHostStatus | % {
    $ServerName = $_.HostName
    Get-AFCacheStatistics -ComputerName $_.HostName -CachePort $_.PortNo | Add-Member -MemberType NoteProperty -Name 'ServerName' -Value $ServerName -PassThru
} | Format-List -Property *   

Stop-SPDistributedCacheServiceInstance -Graceful;


$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}

$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}

Register-CacheHost -Provider SPDistributedCacheClusterProvider -ConnectionString "Data Source=svr-jc-db1;Initial Catalog=SharePoint_Config_2013;Integrated Security=True;Enlist=False" -Account "NT AuthorityNetwork Service" -CachePort 22233 -ClusterPort 22234 -ArbitrationPort 22235 -ReplicationPort 22236 -HostName svr-jc-web2

Get-AFCacheHostConfiguration -ComputerName ComputerName -CachePort "22233"
Set-CacheHostConfig -Hostname SP2013 -cacheport 22233 -cachesize 300
Update-SPDistributedCacheSize -CacheSizeInMB CacheSize
Get-CacheHostConfig -ComputerName SP2013 -CachePort 22233
Export-CacheClusterConfig c: empfile.txt
Import-CacheClusterConfig c: empfile.txt

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount -Identity domain_nameuser_name
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt

Clear-SPDistributedCacheItem -ContainerType DistributedLogonTokenCache

Security hole in O365 Partner sharing

Until further notice I am advising clients NOT to enable partner sharing.  This is because you never know who will be accessing your data from the partner side.  If your partner is a large SharePoint consulting firm, they have no ability to lockdown who can see your data on their side (out of the 100's or 1000's of clients they have). 

To be said another way, this means they have no way to keep random internal employees from checking out your site and data. Until they activate the ability to assign specific people to your accounts, I highly suggest that you stop partner sharing!!!

In other words, think Edward Snowden and Bradley Manning…type of security holes.

Vote for it here on UserVoice:


Azure Workflows cannot call O365 APIs

As part of my 5-day O365 course I have a Workflow section that describes things like deploying workflows via Apps with event receivers that deploy to the Host Web.  Also a part of the lab is how to "theoretically" call an O365 API from workflow.  Unfortunately, you cannot call O365 APIs from workflows that live on-premises or in O365.  The reason is two fold. 

  • For on-premises, there is a buffer overflow in the Workflow Manager service (1.0, CU1, CU2 and 1.0 refresh) that barfs on large DynamicValue HttpHeaders in the HttpSend request.  Reference this post for the error you will see.
  • For O365, there is a special STS validation layer that barfs on the Azure AD access token (Error is "JsonWebToken.Issuer != clientId@realm"). If you pass the token in anything but the "Authorization" header it will pass right through, but it will not pass through in the "Authorization" header.

Therefore, the only avenue you have is to use "Basic" auth when making the calls.  This means you must store the user's username and password somewhere rather than allowing them to go through the basic OAuth process the way it should be.

If you would like to be able to do this, vote for it on UserVoice here:


Google Apps vs Azure Apps vs SharePoint Apps vs LiveId Apps vs Yammer Apps – Introducing Auth0.com

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 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.

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.


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

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

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.


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.