Want Multi-Factor Authentication When Accessing Web Services? Try AAL and AAD

Ah, what a day! The news on the Windows Azure AD features in the Windows Azure portal were on fire today if you missed them, check this out before going any further.

The phone-based multifactor authentication preview is probably my favorite new feature. For details, check out this walkthrough; but in a nutshell,  this new feature allows you to get selected users to authenticate with the directory by using both classic username/password AND exchange security codes via SMS messages (or voice call) from their registered phones. I love it because of its simplicity, especially if compared with more traditional methods like smartcards or hard tokens. That allows slipping this extra check in the Web authentication flow very easily, technically it’s mostly another redirect.

Unfortunately, adding another authentication factor to Web services-based solutions is not as easy: that usually entails redeploying the clients, given that the logic for prompting the user for the extra factors, and actually pumping the results on the wire according to the characteristics of the method of choice. Right? RIGHT?

Ehmmm… no. Or, at the very least, not necessarily!

Almost one year ago I wrote a long post (surprised?) on the benefits of introducing a browser surface in the context of  rich client authentication flows: luckily you don’t have to read it all – the “General Idea” section holds the relevant info. In fact, I can summarize the entire thing in one sentence: if you rely on a browser window for driving the authentication from the server side, you can enjoy in a rich client the exact same benefits you get when authenticating with a Web site. Including NOT having to roll out a new client when adding extra authentication logic.
Sounds too good to be true? I can prove that last assertion, by walking you through a very real scenario.

Remember the ASP.NET Tool for Windows Azure AD? It is a rich client (its UI lives within VS itself) which performs authenticated calls (to the Graph API, to create a ServicePrincipal for the app it is configuring) secured against AAD (via AAL).
As mentioned, yesterday AAD added the ability of enforcing multi-factor authentication. In a traditional Web services client world, the ASP.NET Tool for Windows Azure AD would NOT be able to take advantage of the new authentication flow: not without a redeploy of the client, or at the very least of the authentication libraries it uses.

Well, guess what. AAL does use a browser based flow to acquire from AAD the token it needs for calling the Graph. In yesterday’s walkthrough I added to my test tenant an admin which requires the new multi-factor authentication. Why don’t we try to use the ASP.NET Tool with that admin user, to put to test my theory that I’ll be able to use the new auth flow with old bits.

You know the drill: select the project, go in the Tools menu and choose Enable Windows Azure Authentication; then enter the test tenant domain.

AAL will display the usual authentication dialog. You’ll get prompted for the credentials of an administrator, the usual username and password…

…but if the user you entered is one for which you assigned the multi-factor authentication requirement, your authentication experience won’t be over yet. The AAL authentication dialog will show the following…

…and your phone will buzz with a message. Reply back with your code…

…and the authentication dialog will finally close. After a brief wait, the tool will inform you that the app configuration took place successfully.

That means that the tool successfully called the Graph, which in turn means that it successfully got a token from AAL.

In summary. I just used old bits to take advantage of a new authentication flow – and a multi-factor one nonetheless. Q.E.D.!

You know, I didn’t really *need* to see this happening to know that AAL’s approach supported arbitrary server-driven auth, new authentication factors that weren’t even considered at the library’s inception, and so on; that’s why we designed it the way it is. But still… having the chance to see that playing out exactly, I don’t know…  it just makes me happy

Remember, both AAL and the phone based multifactor authentication are still in preview: don’t miss the chance to give feedback!