MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

https://www.facebook.com/dialog/oauth?client_id=&redirect_uri=&
scope-read_stream&display=popup&response_type=token
https://accounts.google.com/o/oauth2/auth?client_id=&redirect_uri=&
response_type=code&scope=http://picasaweb.google.com/data
where and are replaced with whatever is specific to the app. Twitter and
Flickr, for their parts, use OAuth 1.0a protocol instead, so much more ceremony goes into creating the
lengthy OAuth token to include with the requestUri argument to authenticateAsync. I’ll leave it to the
sample code to show those details.
Tip Web authentication events are visible in the Event Viewer under Application and Services Logs >
Microsoft > Windows > WebAuth > Operational. This can be helpful for debugging because it brings
out information that is otherwise hidden behind the opaque layer of the broker.
Single Sign On
What we’ve seen so far with the credential locker and the web authentication broker works very well to
minimize how often the app needs to pester the user for credentials. Where a single app is concerned, it
would ideally only ask for credentials once until such time as the user explicitly logs out. But what about
multiple apps? Imagine over time that you acquire some dozens, or even hundreds, of apps from the
Windows Store that use external authentication providers. It could mean that you’d have to enter your
Facebook, Twitter, Google, LinkedIn, Tumblr, Yahoo, or Yammer credentials in each app that uses them.
Sure, you might need to do that only once in each individual app, but the compound effect is still
tedious and annoying!
From the user’s point of view, once they’ve authenticated through a given provider in one app, it
makes sense that other apps should benefit from that authentication if possible. Yes, some apps might
need to prompt for additional permissions and some providers may not support the process, but the
ideal is again to minimize the fuss and bother where we can.
The concept of single sign on is exactly this: authenticating the user in one app (or the system in the
case of a Microsoft account) effectively logs the user in to other apps that use the same provider. At the
same time, each app must often acquire its own access keys or tokens, because these should not be
shared between apps. So the real trick is to effectively perform the same kind of authentication we’ve
already seen, only to do it without showing any UI unless it’s really necessary.
This is provided for in the web authentication broker through the variation of authenticateAsync
that takes only the options and requestUri arguments. In this case options is often set to
Web-AuthenticationOptions.silentMode to prevent the broker’s UI from appearing (but this isn’t
required).
To make silentMode work the broker still needs to know when the process is complete. So what
callbackUri does it use for comparison, and how does the provider know that itself? It sounds like a
situation where the broker would just sit there, forever hidden, while the provider patiently waits for
input to a web page that’s equally invisible! What actually happens is that authenticateAsync watches
665