At first glance, and in reading different documentation (including the first edition of my book–I’m now working on the second), it seems like the Web Authentication Broker in WinRT is meant for a few key OAuth identity providers like Twitter and Facebook. That was at least my initial impression, but it’s mistaken.
The Web Authentication Broker is actually meant for any service that provides authentication. It’s primary purpose is to avoid collecting credentials in client apps and then transmitting those credentials over HTTP requests. Ideally, if apps always protected those credentials with appropriate encryption and using SSL over HTTP, and avoided storing any credentials on the client in plain text, then the web auth broker might not be necessary. But apps usually aren’t written that securely, so it’s best to authenticate directly with the service and have that service provide the app with an access token of some kind.
This is what the Web Authentication Broker is meant for. By invoking it–providing with your service’s authentication URI–an overlay appears above your app and displays the service’s page directly. This means that any and all information that the user enters at this point is going securely to the service and not to the app. The service, as described in the guidance for web auth broker providers, can provide whatever series of pages it needs for its own workflow, but at the end of it all it responds with a token that the client can use in subsequent calls.
So if your app in any way needs to collect credentials to authenticate with a service, consider using the web auth broker for this purpose and create the necessary pages on your service for this purpose. With just a little work, you can craft those pages so they look great within the broker window and integrate nicely into your app experience.