30 Days of Zumo.v2 (Azure Mobile Apps): Day 4 – ADAL Integration

I went through the process of using Azure AD in a server-based flow in the last article. Sometimes, however, you want to have the native experience. The Facebook Client SDK, for example, deep-links into the Facebook app and allows you to log in without actually entering a username and password – you just click on Approve for the application. Single Sign-on tends to be the big case for using the client-flow. It provides a native experience.

In this tutorial, I’m going to integrate ADAL into my Apache Cordova application and use the token that is provided to authenticate to Azure Mobile Apps.

Note: ADAL is not officially supported on Apache Cordova at this time. If you want to use a platform that is supported, ADAL is supported on native iOS and Android, .NET, Universal Windows Platform and Xamarin. Pick your favorite platform instead. The settings that I configure will be the same irrespective of the platform chosen.

Step 1: Configure a new Native Application in Azure AD

In the prior article, I configured a Web App – actually, Azure AD configured a Web App for me. Unfortunately, that won’t work with ADAL – you need to configure a new Native Application. Log on to the Azure Portal, click on Browse> and then Active Directory – this will get you to the right place in the Classic Portal – right into your default domain on Azure AD. Click on the APPLICATIONS tab.

Screen Shot 2016-03-19 at 1.52.05 PM

Click on the ADD button at the bottom of the window.

Screen Shot 2016-03-19 at 1.52.46 PM

You are developing an application, so the choice is obvious here.

Screen Shot 2016-03-19 at 1.53.31 PM

You can enter any name for the app – I tend to copy the project name. Most important, however, is that you need to select the Native Client Application option before continuing.

Screen Shot 2016-03-19 at 1.55.15 PM

Note that I’ve picked something completely random for the redirect URI. It has to be a valid URI, but it can really be anything. Once you are done, click on CONFIGURE to see the properties you need:

Screen Shot 2016-03-19 at 1.56.07 PM

In order to work with Azure Mobile Apps, we need a little more. Specifically, we need to add the Azure Mobile Apps callback URI to the redirect URI. You can do this by adding it in the box under the Redirect URIs section and then clicking on save. The URI you want to add is:


Like this:


You will also need to give the native client permission to access the web client. You’ve already set the web client in the last article. Scroll down to the bottom of the CONFIGURE screen and click on the Add Application button:


Click on the dropdown for “Microsoft Apps” and select “All App”, then click on the big tick next to the search box. Your web application will appear:


Click on the plus next to the web application and then click on the tick to continue (in the lower right corner).


Finally, click on Delegated Permissions next to the web application. A short list will drop down – generally only containing an “Access” option. Check the box next to Access. Then click on Save at the bottom of the page.


Yeah – that was as non-obvious as it looks. You will need the Client ID and Redirect URI that you entered later on.

Write some code for Apache Cordova

For reference, writing the code was easy. Getting it to emulate properly was a royal pain in the neck. There are problems with ADAL on iOS 9.x because of a security integration. There are problems running ADAL within Ripple because of a cross-bridge problem. There are problems running ADAL inside the default Android Emulator because one of the returned screens are too big. I was honestly swearing at Apache Cordova at the end of this. However, I finally got it to work using an Android build and the Visual Studio Emulator. Let’s start with the code, which is all contained within the www/js/index.js file:

    // The ADAL Settings
    var adal = {
        authority: 'https://login.windows.net/common',
        resourceUri: 'https://30-days-of-zumo-v2.azurewebsites.net',
        redirectUri: 'https://30-days-of-zumo-v2.azurewebsites.net/.auth/login/done',
        clientId: 'f35243c4-a4da-4b97-8beb-6a1cf2f76976'

The resourceUri is the URI of your app service. The redirectUri is the additional Uri that you added to the Azure AD configuration for your native client application, and the clientId is exactly what you would expect.

        // Wire up the button to initialize the application
        $('#loginButton').on('click', function (event) {

            authenticate(function (data) {
                console.log('data = ', data);

            //client.login('aad').then(initializeApp, function (error) {
            //    console.error(error);
            //    alert('Failed to login!');

My first alteration is to throw out the server-flow and use a new function – authenticate() – to do the authentication flow. This has a callback and I just dump what I’ve received. Finally, let’s move on to the actual authentication flow:

     * Authenticate with the ADAL Plugin
     * @param {function} authCompletedCallback the function to call when complete
    function authenticate(authCompletedCallback) {
        adal.context = new Microsoft.ADAL.AuthenticationContext(adal.authority);
        adal.context.tokenCache.readItems().then(function (items) {
            if (items.length > 0) {
                adal.authority = items[0].authority;
                adal.context = new Microsoft.ADAL.AuthenticationContext(adal.authority);

            // Attempt to authorize user silently
            adal.context.acquireTokenSilentAsync(adal.resourceUri, adal.clientId)
            .then(authCompletedCallback, function (p) {
                // We require user cridentials so triggers authentication dialog
                adal.context.acquireTokenAsync(adal.resourceUri, adal.clientId, adal.redirectUri)
                .then(authCompletedCallback, function (err) {
                    console.error('Failed to authenticate via ADAL: ', err);
                    alert("Failed to authenticate: " + err);

This code won’t actually work – in that the authentication may or may not succeed, but the button won’t go away to be replaced by our app as we normally do. We’ve got more work to do. If you do run this project, however, you can examine the data that comes back:


Note the accessToken – this is the piece that we need to pass into Azure Mobile Apps when we swap it for a ZUMO token. You can also see some great information in this object already. If it isn’t there, you can ask the Azure AD Graph API for more information directly because you have the Azure AD token.

Configure Azure Mobile Apps Authentication

Azure Mobile Apps won’t actually accept this token yet. That’s because the token is being generated for a different application than the one configured. To configure Azure Mobile Apps, we have to go through the Advanced setup. Log on to the Azure Portal and select your App Service from the list of resources. Click on All Settings, then Authentication / Authorization, and finally click on the Azure Active Directory configuration:


Click on Advanced, then enter the Client Id and the Issuer Url. The Client Id is the same one that your app is using. Don’t know the Issuer Url? Well, I don’t blame you. Fortunately, that’s based on your Azure AD tenant, so it’s likely to be correct. However, if you don’t have it and are starting from scratch, you will see it in the data coming back from ADAL (in the userInfo.identityProvider property), or you can get the GUID involved from the Azure AD endpoints – go to the Azure AD configuration screen and click on View Endpoints at the bottom of the window.

More Apache Cordova Code!

Now that we have an access token, we can swap it for the ZUMO token easily:

        // Wire up the button to initialize the application
        $('#loginButton').on('click', function (event) {

            authenticate(function (data) {
                client.login('aad', { 'access_token': data.accessToken })
                .then(initializeApp, function (error) {
                    alert('Failed to authenticate to ZUMO!');

The nice thing about the Visual Studio Emulator is that you can leave it running – the start up is much quicker (compared to, say, the Google Android Emulator). I’m not sure why I wasn’t using it before, except to prove a point. Perhaps the only point I proved was that I like pain.

When you run this project, the authentication flow works and you get your project back.

Next Steps

This was a complex process. I actually tried all the client flows – either in Cordova (Facebook using phonegap-facebook-plugin for example) or in a Xamarin app using the appropriate NuGet packages. Azure AD was by far the most complex setup.

Next time, we’ll take a look at how you can provide a sign-up process using a third-party service instead of the Azure App Service Authentication / Authorization capabilities.

2 thoughts

  1. Hi, I’ve seen your article which used auth0 for custom authentication with azure mobile apps. After looking at the third party auth (next article) will you be visiting “custom auth” i.e. table of users/passwords? I’ve been scouring the net looking for examples on this and can’t find anything to learn from – closest was custom auth but using .Net web api’s but even then the sample code was a bit light.


Comments are closed.