XAuth a useful service with a poor name

The Authosphere is a buzz this morning with XAuth. My first instinct when I started seeing headlines about it was, yet another OAuth competitor?

It turns out it is nothing of the sort and it could turn out to be a very useful service. “Service” you say, isn’t it a standard? It really is a service and not a new authentication standard. But I’ll get to that.

What is it?

The way you can look at XAuth is that it is a cross domain cookie containing a list of services that you use.

What does it solve?

The problem that this aims to fix is really a UI one, not a security one. If you know the user already uses Google accounts and Meebo, there is no need to over clutter your user interface with login buttons to 40 different social networks.

It could work really well hand in hand with both OpenID and OAuth to minimize the user interface for connecting to them. OpenTransact also has potential uses for XAuth as it could be used on a payment form to filter the list of payment types a user uses.

So how does it work?

XAuth essentially defines 3 different parties to the flow:

• Extenders are web services that a user is logged into that present some public API. These often have the same role as the OpenID providers and OAuth Providers.
• Retrievers are web services that want to discover and consume one or more of the Extenders. In OpenID terms these are relying parties and in OAuth terms these are Consumers.
• XAuth.org is the final party. All communication of XAuth happens through an iframe and javascript hosted here. This is just static hosting, all data is stored in the users browser.

How do I use it?

As a developer it is pretty easy to do. Most of the work is in the Javascript layer and there really is very little that needs to be done on the server backend side. As I understand more about the process I will update this page.

XAuth is implemented as a javascript library you import in your header:

<script type="text/javascript" src="http://xauth.org/xauth.js"></script>

This script creates a hidden iframe on your page with the following page http://xauth.org/server.html.

Extender implementation

If you are an Extender, you extend your service by calling the XAuth.extend() function with a token. I would expect this to be done once a user logs in to the Extender service.

XAuth.extend({
  token: "bb87aef641b8f29023a8c207f",
  expire: 1271773157402,
  extend: ["www.meebo.com", "www.youface.com", "*"],
  callback: extendCallback
});

The token is a XAuth specific token, which I don’t completely understand yet. The demo code just generates a random token. Here is what the spec says:

this is the XAuth token, created specifically for use with XAuth and used by an auth extender to request additional services from the extender. This token will be stored with the canonical domain as the key.

My guess is that it should say:

this is the XAuth token, created specifically for use with XAuth and used by an auth Retriever to request additional services from the extender. This token will be stored with the canonical domain as the key.

The spec doesn’t mention more here but I imagine this could be used together with OAuth somehow for a really low permission OAuthToken. But lets see what implementers do with it.

The extend allows you to limit the token to only certain trusted domains. Use “*” to allow anyone access.

The optional callback method is called with the following data:

{
  "cmd": "xauth::extend",
  "id": 0
}

Once this has been called a record is created in the HTML5 Local Storage for the http://xauth.org/server.html page:

If you are unfamiliar with HTML5 Local Storage, think of it as a more evolved form of cookies. Some people have called in browser based NoSQL.

As part of your logout code you should also call XAuth.expire(), which removes it from the list of tokens.

Retriever implementation

The retriever is also pretty simple to implement. You make the call to the XAuth.retrieve() function:

XAuth.retrieve({
  retrieve: ["www.meebo.com", "www.youface.com", "xauth.org"],
  callback: retrieveCallback
});

You must list all the Extender domains you are interested in and the callback function is called with tokens for each of the available Extenders.

{
  "cmd": "xauth::retrieve",
  "id": 4,
  "tokens": {
    "xauth.org": {
      "token": "bb87aef641b8f29023a8c207f",
      "expire": 1271773157402
    }
  }
}

Now remember XAuth doesn’t say what to do with this information. Everything from now follows the regular API’s you already use. I expect that this is initially going to be used to hide various openid login widgets in the beginning.

For an interactive spec/testing console go to the XAuth Specs page.

User privacy issues

So as a user how do you control this? Do I really want these sites to know what I use?

At the XAuth home page you will find this control panel:

It allows you to switch XAuth off completely and to see and manage the tokens Extenders are publishing for you.

Service or Standard

I guess it really doesn’t matter, but strictly speaking this is a service not a standard. It does rely on the XAuth server to provide js and the iframe page.

This is Discovery not Auth

I find probably the biggest issue with XAuth is the choice of name. XAuth is not an authentication protocol. I would call it a discovery protocol. It has more in common with WebFinger (again in a complimentary way) than with authentication protocols like OpenID and OAuth.

Having spent more than 2 years explaining to people that OAuth and OpenID are not the same, this just adds more confusion. Names are really important.

I also think the choice of Extenders and Retrievers is confusing. I think using Provider and Client would be clearer. Lets not invent more terminology if it isn’t necessary.

Conclusion

I think this could be really useful. It looks very easy to implement for both Extenders and Retrievers. The usage of HTML5 functions also hints at a bunch of new services that are now possible.

Of course with any of these kinds of services until there are Extenders out there, very few Retrievers are going to implement this. I understand that both Meebo and Google will support it.

As it is so easy to implement, it might not hurt at all for smaller startups to implement Extenders. It could be a way to promote your API.