Using XAuth to simplify the social web

APR 19, 2010
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.



Posted by Chris Messina, Social Web Team
posted in:
Previous
Next