Here’s an “interesting thing” that I came across the other week. I go to the Windows Store on Windows 8.0 and I install the Metrotwit application and then run it then it asks me to log in to Twitter.

In order to do that, it uses oauth authentication and in order to do that it uses the WebAuthenticationBroker.

The broker pops up a standard piece of UI;

and then if I authenticate with Twitter then the oauth dance happens and when that’s over the application has gained the right to access Twitter (in a particular, scoped way) on my behalf without the application ever getting hold of my Twitter credentials.

A couple of things about the Web Authentication Broker.

Firstly, the UI is consistent so that the user can recognise it as something that belongs to Windows (albeit with the opportunity to preserve the branding of the site where the oauth authentication is happening).

Secondly, the UI is a peculiar one because it doesn’t run inside of the application itself. If it ran inside of the application then it might not be too hard for the application to acquire the credentials that the user is using to authenticate (i.e. in this case my Twitter username and password) and perhaps send them somewhere other than to Twitter or even just to persist them somewhere for re-use at a later point.

To avoid that, the UI is a system provided mechanism that runs in a different application container. There’s more on the details of that up here on the MSDN site but the essence is that the broker runs in a separate box such that the mechanics of the authentication process are not surfaced to the app but, instead, the protocol data is presented to the app at the (successful) conclusion of the authentication process.

If I go through these steps on Windows 8.0 then I see a couple of things stored in the “Credential Manager” – I tried to blank out a few of my personal details in the screenshot below;

and so it’s fairly clear that Metrotwit (as an example) has stored a secret and a token and if I run Metrotwit again it’s not going to need to go through this step again with Twitter (unless the tokens expire which I don’t believe they automatically do for Twitter) so it can just continue to talk to Twitter on my behalf.

Those details can (and by default I think are) roamed to other devices such that if I install Metrotwit on a second device then it can automatically log in without having to bother me for credentials again.

However, if I perform the same set of steps on Windows 8.1, I see something a little different – after the WebAuthenticationBroker has displayed the Twitter UI and I’ve authenticated with Twitter I get;

This is different from the app remembering authentication secrets/tokens for me and if I click “Yes” then I see one more entry in “Credential Manager” than I had on Windows 8.0;

and so it’s clear that Metrotwit is doing whatever it was doing on Windows 8.0 and is storing a secret and a token but Windows (or, at least the Web Authentication Broker) is now doing a little bit more work because it’s also storing a password that it has associated with twitter.com.

What that means is that if I go and install another Twitter application from the Windows Store like Rowi that also uses the Web Authentication Broker to authenticate with Twitter then when I come to authenticate I see;

where my credentials have been pre-populated into the dialog so that I don’t need to type anything (which might seem like a small step but it can be a bit annoying on a touch screen device).

In this case, I decided not to log into Rowi so Rowi didn’t get to authenticate with Twitter and store anything on my behalf.

It’s possible for both the credentials that the Web Authentication Broker is storing (in this case for Twitter authentication) and that the app is storing (e.g. the secret/token that Metrotwit was storing) to be roamed across my machines so that either;

1. The first time I run Metrotwit on a secondary machine, it can already log me straight into Twitter because it has roamed the auth secret and token.
2. The first time I run Rowi on a secondary machine because I didn’t actually log in on the first machine, Rowi has to authenticate to Twitter and so invokes the Web Authentication Broker but that broker has stored credentials which have roamed so at least the authentication dialog can be pre-populated saving the user the hassle of typing in those details again.

In the description of the Web Authentication Broker there’s another interesting twist – quoted from the page;

“The broker selects a dedicated app container that is separate from the calling app or any other app on the system and clears any persisted cookies.

Note  This app container is never shared between two apps simultaneously unless the broker was started in the single sign-on (SSO) mode.”

and there’s a further description about the Web Authentication Broker running in the Single-Sign On Mode (SSO). I find the page a bit hard to fathom though so perhaps this video below which also has a description of Single Sign On mode is a better reference;

Within there is a section on the Web Authentication Broker (starts at 17 minutes) and a section on using it for Single Sign On (starts at 27 minutes) and that ends at around 36 minutes.

I think this is to provide a better experience around a scenario such as;

1. App1 runs and asks user to authenticate with Service Provider 1.
2. App2 runs and asks user to authenticate with Service Provider 1.

and the user is left puzzled as to why they keep having to sign in to “Service Provider 1” – that said, switching on the SSO mode requires the back end to have registered the unique SIDs of the client applications that want to work this way so I’m not sure of its general applicability but it’s worth being aware this secondary mode.