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:
app client SDK library asks site to prepare an authorization URL for the aad provider, as configured at the site.
we see authorization server of AAD invoke the (FP-capable) websso service of MicrosoftOnline
we see the cookies at the FP cause it to return an HTML-pahe encoded post-ed ws-fedp response XML stream.
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).
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: