Monday, April 19, 2010

Using XAuth to simplify the social web

Earlier today Meebo announced Extended Authentication (XAuth), an open platform that makes it possible for users to bring their preferred services with them across the web.

To learn more about XAuth and why we're among the supporters of this technology, check out our post on the Social Web Blog.

From a technical perspective, we wanted to offer you some additional insights into how this technology works.

If you visit Meebo's XAuth page, you should see an array of logos:


When this page loaded, it requests the list of services that have been registered with XAuth by making an HTML5 window.postMessage request to xauth.org. As you can see in the graphic, no active sessions were detected.

When the user clicks through to one of the linked demo pages — we'll use googxauthdemo.appspot.com in this case — the same JavaScript is loaded from xauth.org. When the user successfully authenticates, some basic information is pushed to the browser's HTML5 localStorage:

<script type="text/javascript">
function doLogin(doneUrl) {
/* Tell XAuth.org that a user has just signed into Google on this browser. */
XAuth.extend({
// reveals "someone is logged into Google"
token: "1",
// Expires after 24 hours or if the user explicitly logs out
expire: new Date().getTime() + 60*60*24*1000,
// Allow any domain to read this info (could also be a whitelist of partners)
extend: ["*"],
// Optional callback function once extend() has completed.
callback: makeRedirectFunc(doneUrl)
});
}
</script>

This information — that the user has an active session at googxauthdemo.appspot.com — is now available to any site on the web (because extend: ["*"] uses the wildcard case to make this information world-readable; providers can also choose to restrict access to this information to certain domains or partners).

Upon returning to meebo.com/xauth, the page requests the list of active sessions from XAuth, and passes the browser an array of domains that the browser will match against the local storage for xauth.org:

<script type="text/javascript">
XAuth.retrieve({
retrieve: ['xauth.org', 'googxauthdemo.appspot.com', 'xauthdemo.mslivelabs.com'],
callback: receiveTokens }
);
</script>

The major performance and scalability benefits of this design are a result of the single HTTP request made to xauth.org to determine which services are currently active, rather than one-request-per-domain. The request and response are also purely client-side, so there's no waiting for a server to look up anything in a database — and the XAuth JavaScript files get cached after they are first retrieved, making XAuth overall very efficient.

Once the tokens are retrieved the program iterates through them looking for matches, and then modifies the interface according the service token discovered, like this:

<script type="text/javascript">
function receiveTokens(responseObj) {
var tokens = responseObj.tokens;
var token = tokens['xauth.org'];
var partners = {};
var tokensFound = false;
if (tokens['googxauthdemo.appspot.com']) {
partners['google'] = true;
tokensFound = true;
var status = document.getElementById('status-google');
status.innerHTML = 'Signed In!';
status.style.color = '#0A0';
}
}
</script>

In this way, site publishers can detect a user's set of active and preferred services, or request a subset of known services, and present only those services which are known to be currently active. In practice, the list of services provided at any given time by xauth.org should not be considered exhaustive, but instead a suggestion for how to prioritize complex service selection dialogs and interfaces, like those known as "NASCAR" interfaces.

For more technical information about XAuth, please read the spec, or visit the informational page on xauth.org.

15 comments:

  1. Cool.. will hack it soon .. :-)

    Panggi Libersa

    ReplyDelete
  2. OpenId, Oauth, XAuth?! Can someone explain it all to me?!

    ReplyDelete
  3. @Schultzter,

    OpenID is for Authentication
    OAuth is for Authorization to access data
    XAuth is an personalized registry of apps

    I will post a detailed comments for each of these.

    ReplyDelete
  4. Hey Chris,

    Thanks for a great writeup!

    Small correction on performance and scalability: since all the xauth tokens are stored locally in the user's browser, *no* http requests are required to determine which services are currently active.

    Many will surely include the JavaScript from xauth.org, but extending and retrieving services uses a simple postMessage protocol and can be accessed without the xauth.org JavaScript library.

    ReplyDelete
  5. Isn't xauth.org a centralized service? Haven't you fought the last few years against centralized services? Chris it feels you quite never step back and criticize anymore.

    I would be interested if you had also showed how one can be made aware they are using Xauth and how they can turn it off, aside from having to go to the xauth.org website and disable it (what does it even mean?)

    Also, what a terrible terrible name that doesn't tell you what it's all about.

    ReplyDelete
  6. On the other hand, half the services I'm a member of is because of the NASCAR line-up on a site I visit!

    ReplyDelete
  7. @Marcus Westin: I suppose you're right — but there's still at least one HTTP request to fetch the JavaScript at some point so I think I'll leave it as is. My point was really to try to provide contrast between this approach and the one where you have to ping EVERY service to check if there's an active session!

    @Lawouach: xauth.org is a centralized service, you're absolutely right. And I had my [strong] reservations about this kind of service when I first heard about it. But the reality is this: while this functionality and set of preferences should belong on the client-side (as many of us are aware and have argued) that has *not* happened. The work to make that happen is of course ongoing, but it makes no sense to sit idly by while single-providersolutions overtake the marketplace.

    I think that over time XAuth will prove to be a useful stopgap demonstration of a solution to a problem we've long been aware of but until now, had not marshaled the collective will to meaningfully address.

    In fact, XAuth is so promising because the goal is that any provider should be able to register itself on your behalf, meaning that if you want to use your own custom sharing service or identity provider, you should be able to — and then share that information — proactively — with the sites and services you visit.

    XAuth does more to leverage the playing field than I think you might realize at first glance.

    ReplyDelete
  8. уєα ι мιѕѕ мι ƒσηє вℓσωιη υρρ тєω..ℓσℓ. вυт ιмα тχт унυ ωєηєνα ι кαη

    ReplyDelete
  9. Wow! This is very cool I think, since the request and response are purely client-side. Thank you for sharing.

    ReplyDelete
  10. Ok great, how do us non-programming types use it?

    ReplyDelete
  11. @Duderino, I don't see it being very feasible for non-programmer types to be able to implement this very well... sure you can plop the js on your site, but it's likely the user will want to use you app as well, or login with credentials from another network, or post to both accounts (like facebook and twitter) at the same time or something.

    ReplyDelete
  12. Thanks for the project... Meebo?

    Anyway, Hahaha. Friends think I'm crazy (when I was trying to tell them) of "they (not you) are sort of literally using DIV ID elements as a messaging gateway ... 'to blah blah blah central rpc server!'

    Anyway, pretty nice.... Although there is room for better. Ask me!

    like ... 347-556-1945

    ReplyDelete
  13. This comment has been removed by the author.

    ReplyDelete
  14. So XAuth+OpenId+OAuth is the answer to Facebook's challenge? Where does OpenID Connect fit in?

    ReplyDelete
  15. Can we do something to the monopoly!

    ReplyDelete