Thursday, 16 March 2006
While it’s tempting to say that cookies are evil (the fru-it of the dev-il), using them for authentication isn’t actually that bad, from a REST standpoint; the main loss is that you can’t use standard mechanisms to log in, instead relying on an HTML form. This brings problems with non-browser clients, such as RSS aggregators, WebDAV and CalDAV clients, and XSLT stylesheets.
In short, you lose some of the network effects of the Web (which is no small loss, BTW), but it’s isn’t inherently crossing REST, IMO. I can even imagine a microformat that helps machines understand login pages, to mitigate this; after all, we already have the converse (the “don’t you dare save this password” flag that banks demand HTML supports).
OTOH, using cookies for “personalisation” on the server is abusing the Web; you lose cacheability, the ability to identify different resources, etc. Unfortunately, the proposal at hand does just that — but with HTTP authentication replacing cookies. How, exactly, is this RESTful?
Furthermore, expecting your users to understand that an auth dialog popping up in certain contexts is a means of logging off will work for a small population of geeks, but never for the wider Web.
Finally, spraying Authorization request headers all over your site will kill cacheability, one of the key benefits of REST. Indeed, the author suggests that Cache-Control: no-cache be sent with all responses from such a site. Ouch.
How Do You Get Into An Authentication Workshop?
That’s not to say that we can’t do better than cookies, as I’ve pointed out before. This week, the W3C held a Workshop on Transparency and Usability of Web Authentication.
By all accounts I’ve heard, it was interesting, but I think the focus of the Workshop — cleaning up the current Web auth story — isn’t ambitious enough. As RFC2617’s security considerations say, Digest authentication is a huge leap over Basic, but there are still miles to go, in terms of both security and usability.
That means an HTTP authentication scheme that is capable of supplanting cookies, while still retaining the benefits of REST (or even getting some new ones). A tall order, but I think it might actually be pretty easy. More soon, hopefully.