Analyzing the idtoken flow between store app WAB and mobile site


By default, upon SSO-enabling the Web Authentication Broker (WAB) used in a windows store app (WinJS version) talking to AAD via MicosoftOnline, the experience is one in which the SSO UI pops up the windows of the broker.  If the user has chosen to “stay signed in”, the broker windows quickly removes itself – since the mechanisms pick up a token automatically minted by microsoftonline/AAD from the stored session cookies.

We don’t like that UI – since 9 times out of 10 a fast windows popup occurs – that does nothing. It just looks like a flashing screen. So, we want to get to the next step of arming SSO – storing the site token in a keyring/localstore so that the WAB does not even get invoked.

Before we get there, lets round out our tool chain.

First we see the flow:

image

app client SDK library asks site to prepare an authorization URL for the aad provider, as configured at the site.

image

we see authorization server of AAD invoke the (FP-capable) websso service of MicrosoftOnline

image

we see the cookies at the FP cause it to return an HTML-pahe encoded post-ed ws-fedp response XML stream.

image

we see the assertion consuming service of the AAD tenant processing the websso response, generating an idtoken message (an oauth response type, contrasting with the more typical returing an auth_code).

image

image

we see the node.js site convert the idtoken into a redirect back to the WAB, waiting on an ms-appx protocol handler. The site has also swapped the idtoken for one of its own making, now to be delivered to the waiting client app.

To make fiddler capture the flows from the authhost.exe process underlying the WAB, we used its windows 8 “loopback setup” feature, for the sid in question:

image

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in AAD, azuremobile. Bookmark the permalink.