New ADAL 3.x preview–device profile, Linux and OS X sample

It’s time for a new developer preview of ADAL 3.x. We have some important news – hang on to your hats!

Device profile support – Net Core sample on Windows / Linux / OS X

Azure AD added support for a new, super interesting OAuth2 token issuance flow – described here. In a nutshell: say that you have an app running on a device that has limited input/output capabilities, like a Nano sever or any device with just a textual display. Say that your app needs to invoke API as an Azure AD user: the token acquisition flow requires the user to do things that cannot be accomplished via text only output, such as granting consent or dealing with multiple authentication factors. What now? Enter what we affectionately call the device profile flow. When the app needs to get a token as a user, it uses the textual output of the device to prompt the user to navigate to a given URL, using a web browser on any other device the user has access to: a smartphone is the most classic example. The text output also provides a unique code and instructs the user to enter such code in the page from the aforementioned URL. That will trigger a normal browser based authentication flow. As soon as the flow ends successfully, the original app on the text-only device (which has been polling a specific endpoint the whole time) receives the requested token and can go ahead to securely call the API it needed to access.

That is super handy for working with limited devices. In fact, it opens up very interesting scenarios on platforms we didn’t touch via ADAL .NET so far – namely, Linux and OS X. That’s to the fact that ADAL 3.x supports .NET Core, you can use it on apps targeting Linux and OS X – but so far you were limited to silent flows only. Whereas with Xamarin we can rely on visual components for hosting the auth experience on iOS and Android as well, we don’t have such classes available in Linux and OS X. However the device profile flow sidesteps the issue entirely, by leveraging an actual browser window handled by the user (as opposed to a browser dialog popped by the library).

If you wan to see the above in action, you can check out a brand new sample that demonstrates the scenario on Windows, Linux and OS X: you can find it at https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-deviceprofile/.

The scenario is the usual directory searcher app, where you can enter the alias of a user and retrieve some basic info about the corresponding user. In this case we implemented it as a .NET Core console, so that you can run it on Windows, Linux and Mac. Here there’s a quick walkthrough.

When you launch the app you get the following prompt.

Let’s say that I want to search for Fabio in my developertenant.onmicrosoft.com tenant. Here there’s the command I need to enter:

As soon as I do that, I get the following prompt:

The message says:

Message: To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code BGUYYEVCQ to authenticate. If you’re signing in as an Azure AD application, use the –username and –password parameters.

Let’s open a browser, navigate to aka.ms/devicelogin and enter the code.

Azure AD recognizes the calling app and offers to initiate the auth flow. From now on, it’s business as usual:

Upon successful authentication, we get the message below.

If we go back to the original app, we’ll find that the requested token has been acquired and used to invoke the graph API and find more info about fabio. QED!

If you follow the instructions in the sample, you can run the exact same dance through Linux and OS X. For example, here there’s the app running on my little Ubuntu VM

Note, the sample is based on ASP.NET5 Beta 8 – but we did test it on RC1 (on Windows) and it works as well.

Conditional access for .NET desktop and Windows Store apps

As you know, you can use Intune for managing access to your SharePoint and Exchange online assets. For example, you can issue policies through which you only allow access from a registered device (via workplace join or Azure AD cloud join). We refer to those scenarios as conditional access scenarios. Well, from this preview onward apps using ADAL on registered devices will automatically perform the device authentication dance which is necessary for complying with those policies and gain access to resources protected via conditional access. Pretty cool!

Windows Phone is no longer supported in ADAL 3.x

ADAL v3.x works with UWP apps, using the exact same assembly used for targeting Windows Store. That means that you can happily target Windows 10 Mobile with the exact same app and use ADAL on it without any worry about continuation model and similar complications that came into play when using the WebAuthenticationBroker (the API used by ADAL on windows store apps for presenting the auth experience) on Windows Phone 8.1.

Supporting two different mobile models for Windows on the same library, one for UWPs and one for Windows Phone 8.1, would be confusing for you and very expensive for us. And given that the features in ADAL for Windows Phone 8.1 would be exactly the same as the ones already present in ADAL 2.x, we decided to drop support for Windows Phone 8.1 from ADAL v3.x. The Xamarin sample has been updated accordingly.
I want to stress that you are not losing anything in term of functionality. If you want to target Windows Phone 8.1, you can use ADAL 2.x – ADAL 3.x would not have introduced any extra features for Windows Phone 8.1 anyway. That does mean a bit more work if you are writing an app targeting multiple platforms: if you are targeting UWP (big windows and Mobile), Windows Store, desktop, iOS, Android or .NET Core you can use ADAL 3.x for all those – but if you also want to add Windows Phone 8.1, you’ll need to add a separate project with a reference to ADAL 2.x. Sorry for any inconvenience this might cause you!

Caveats in this preview

The .NET core support is still being worked on – there are still few areas to tidy up. For example, authentication grants using X509 certificates won’t work in this preview.

Summary

Inching closer and closer to GA, at this point we are pretty much feature complete. Please give it a spin for the new scenarios and keep the feedback coming!