XAuth – a Terrible, Horrible, No Good, Very Bad Idea

A few weeks ago, a handful of web companies lead by Meebo and Google (with moral support from Yahoo!) announced their support for a new protocol called XAuth. The idea is very simple and seemingly appealing – create a sort of shared-cookie service for sites to use to store and find which identity providers a user prefers, solving the OpenID NASCAR problem. It is a similar idea to existing commercial products such as JanRain’s RPX.

I’ve heard about this proposal a few months ago and have been rolling my eyes ever since. Why? Because this is – to borrow from one of my son’s favorite booka terrible, horrible, no good, very bad idea. It is a dangerous and over simplified hack aimed at solving a complex problem – how to manage online identities and improve the usability of distributed identity providers.

The XAuth proposal is a privacy and security nightmare. It relies on the use of a single, shared domain name which is currently under the control of one company – Meebo. While I have nothing against Meebo, other than proposing and promoting this, I certainly don’t trust it to manage the web’s identity preference layer. I heard suggestions of handing control over to the OpenID Foundation, but I don’t trust it either. If it is controlled by a single entity, it fails the most basic test of distributed identity services.

In addition, XAuth is a cookie-like mechanism that suffers from all the same problems, and as such, is an easy target for abuse and manipulation. And guess what – it is an opt-out mechanism per browser.

This is a misguided attempt to solve a problem browser vendors have failed to address. It is true that getting browser vendors to care about identity and innovate in the space is a huge challenge, but solving it with a server-hosted, centralized solution goes against everything the distributed identity movement has tried to accomplish over the past few years.

As for the name, I resent the association between XAuth and the OAuth brand, using a cloned logo and a very confusing name. This is especially true considering it has nothing to do with OAuth, and everything to do with OpenID. And by the way, the name is already taken.

I think I’ll move to Australia.

Update: This post sparked a response from Google’s John Panzer (someone I highly respect, and respectfully disagree with) as well as an interesting thread on the OpenID list. A couple quotes I complete agree with:

From Peter Watkins:

The current XAuth implementation has sites using IFRAME elements to access the XAuth service/JS code. Web browsers send Referer headers with IFRAME, so whoever runs xauth.org is in a position to see information about what Extender and Receiver sites a user accesses. Currently auth.org has pretty good settings — cache control headers telling browsers they can cache the page for a week. But that could change. Move responsibility into the browser and that problem is solved.

Also, xauth.org could start delivering JS code that reports information to the xauth.org mothership in addition to simply “working”. Say the local government tries to compel xauth.org to deliver additional code to specific IP addresses (not that Google has *ever* had any trouble with any government legal pressure, right?). xauth.org could deliver pristine, trustworthy JS to everyone else. How would the government targets, let’s say political activists maybe, be able to tell their privacy was being subverted? Move the function to the browser and that hole is closed.

This is by no means a comprehensive list (shoot, it’s been less than 24 hours since I startd reading up on XAuth), but I think it’s enough that you can’t say there are no privacy issues that going to an in-browser model would solve no privacy issues.

From Philip Hallam-Baker:

As often happens in these debates, we have a proposal that has an acknowledged issue that we are being told isn’t an issue because the developers don’t see it as an issue.

I really take offense when I raise an issue and someone says ‘that does not matter to anyone’ or ‘that issue has been dealt with’. The one issue that I have never found it difficult to get the industry to agree on is the necessity of ensuring that no party gains a proprietary leverage in a communication protocol.

I don’t see how the promise that the issue will be fixed in future changes anything. Either the centralization is easy to eliminate from the protocol or it isn’t. And if it is easy to eliminate then why introduce it in the first place?

The starting point for identity in my view is that I have to entirely own my name. There cannot be any entity that can use the investment I make in my name to extract rent at a future date. No corporation, no not-for-profit, no non-profit, no industry group. Nothing.

(Image adapted from the book “Alexander and the Terrible, Horrible, No Good, Very Bad Day” by Judith Viorst, illustrated by Ray Cruz.)

20 thoughts on “XAuth – a Terrible, Horrible, No Good, Very Bad Idea

  1. Glad you talked frankly about it
    I did not feel very confident with this company, and the one-domain solution really looks like a regression.

    • I think your Churchill quote sums your view nicely, but I still disagree with your conclusion that this is worth doing in the first place. But your answers to the objections raised are more stating the problem then really providing a satisfactory solution. As for the logo, it is on top of the discussion list (http://groups.google.com/group/xauth) as well as on the slides on the site. Chris created the original OAuth logo and as an OAuth-founder, and can do whatever he wants with it (and I get to rant about it). This is not the first time I disagreed with Chris on branding decisions. Clearly, there is not open OAuth governance anymore for the OAuth brand, as the WRAP naming fiasco showed.

      • I can make a new logo. I just needed something in a pinch and thought it’d be easy enough to tweak the OAuth logo. But yeah, perhaps in this case it creates more confusion than clarifies anything.

        Of course, you did go and create an OAuth 2 logo without consulting me, so I guess we have random branding run amok!

        Oh wells, whatev.

      • That wasn’t a logo, it was an illustration (just like the sad little boy featured on this page and the broken token image on the right). I wasn’t the one who copied the OAuth 2 illustration and posted it on the OAuth site, making it an official logo. I don’t make changes to the oauth.net site without first consulting you, Blaine, Larry, or David.

  2. I guess all problems that you indicated can be solved apart from the fact it’s opt-out per browser, because of XAuth’s reliance on HTML5 LocaStorage for per-browser persistence. That would definitely limit the usage of XAuth.

    As for the unfortunate terminology, there’s also xAuth (lowercase “x”, uppercase “A”), a simplified OAuth authentication scheme devised at Twitter to enable API clients obtain an OAuth access token without having been redirected to the browser. http://dev.twitter.com/pages/xauth

    Cheers!
    Shonzilla

    • I have to admit I’m behind on the latest oexchange spec. I’ve looked at it last year and it seems like a reasonable approach with a talented team behind it. I hope to publish a few articles on it soon.

  3. XAuth would only be a middleware solution, where middleware should not really be trusted. Distribution and trust should be left to browsers to solve, however is work being done on this front? Are browsers looking into providing JS access to user preferences of their favourite login solution?

    • I think with the new identity proposal based on OAuth 2.0 (temporarily named OpenID Connect), combined with LRDD/host-meta discovery will allow browsers to detect when a page requires authentication or sign-in, and automatically interact with that page to log the user it, using their browser-stored preferences. The Mozilla Labs team is making some progress on this front with their Weave product (which I hear will be part of Firefox soon). They still have a long way to go but its the first real attempt.

  4. I must have missed something, but I was under the impression that this was adressed by a hack, namely that browser would redirect xauth.org thanks to a local DNS exception, to a 127.0.0.1:xxx adress (I must have got a handful of technicalities wrong in that sentence.) and that Meebo was only hosting the default solution, until browsers-editors set this up.

  5. My main complaint against centralized solutions is that they make the system brittle. What happends when their net connectivity is down because someone somewhere messed up a bgp entry? What if you hack into their server because it was written in php and you found youself a 0day? That would expose everone. It is not a system I would use myself.

  6. I’m not particularly in favour of them doing this, the security is my major concern. Give them 2 weeks and they will have all our information.

Comments are closed.