mnot’s blog

Design depends largely on constraints.” — Charles Eames

Thursday, 16 March 2006

Web Authentication

There’s some excitement out there about “Cookie-less HTTP Authentication.”

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.

I can’t help but feel there’s some sort of REST cargo cult developing; “if it doesn’t use cookies, it must be better.” So, file this one under “interesting hacking, good intentions, bad idea.”

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.


Filed under: Web

11 Comments

Jerome Louvel said:

Very good points.

Also, I have the feeling that "personalisation" with or without cookies is considered harmful in REST, or as you say abusing the Web. Why is it so?

A REST resource can have many representations, so it seems that there is no reason why you can't have different representations for different users (based on the IP address or HTTP authentication or cookies).

What is the best approach for RESTful personalisation, while preserving cacheability of representations?

Friday, March 17 2006 at 1:02 AM +10:00

l.m.orchard said:

Jerome:

Rather than separating a user identifier...

Cookie: userid={USER_ID}
/content/foo/

Why not try something like this for personalization...

/content/{USER_ID}/foo/

This way, the pivot for personalization is a part of the URI identifying the content - rather than as a free-floating stateful value maintained somewhere outside a series of HTTP requests. Representational state transfer, and all that.

And I think when we talk about a resource having many representations, that means that the content is basically the same, just offered in different formats or encodings. If content is personalized, that's not just another representation of the same thing - there's modified and customized content there, by definition.

Changing the content based on IP address or cookies really damages cacheability and the idea that a GET is idempotent, as I understand it.

Friday, March 17 2006 at 4:22 AM +10:00

Mark Baker said:

I pretty much agree Mark, there are some important tradeoffs in this space. But the problem now is that there's little in the way of options for developers, and I think Berend's work provides another option with different tradeoffs, which is good. Yet another one that I think would be of value, would be in placing the credentials - rather than just a token for them - in the cookie.

Friday, March 17 2006 at 8:33 AM +10:00

Chui said:

I came round to pretty much the same conclusion as lm orchard, while playing around with making our document management system talk WebDav.

By placing the user credential inside the URI, it's saying that the resource is particular to people with certain credentials.

One downside is some freshness is lost, say when user B updates a resource, user A might end up seeing the outdated cached copy of the resource.

The other downside is it doesn't quite feel right. A resource shouldn't have to pretend to be multiple resources to different people.

Any reason why HTTP shouldn't have a special header for kerberos-style tickets? It's exactly what cookie-based authentication is trying to achieve, and would also be helpful in the case of federated logons.

Saturday, March 18 2006 at 4:46 AM +10:00

Jonno Downes said:

Re authentication killing caching - this is kind of axiomatic. If you do not want to send a different response to each user, why bother asking people who they are?

Any framework that supports authentication should also support seperating resources that need to protected or personalised (like my inbox at gmail) from resources that dont (like static images or stylesheets).

Anyway, I don't think you need to make it a case of cookies vs HTTP auth. I think the ideal for a REST framework would be when a protected resource is requested, check for either a Cookie header with a valid session cookie in it, OR a HTTP Auth header with a valid username:password in it. If neither are found, return a 401 response in the header and a HTML login form in the body.

That lets you build a nice intuitive UI for interactive users, but also makes it trivial for to people use curl or XMLHTTP or whatever.

Sunday, March 26 2006 at 2:00 AM +10:00

Mark Nottingham said:

Jonno -

Authentication can be used for personalisation or for authorization; they’re orthoganal. If you’re doing personalisation, the URL, not the credentials, should be the key to the personalised content.

I agree that you can use both cookies and HTTP auth as a stopgap measure, but that increases your attack surface, QA load, etc. It would be better if — in the long term — we had one solution.

Sunday, March 26 2006 at 6:59 AM +10:00

Mike Schinkel said:

@Mark >> If you’re doing personalisation, the URL, not the credentials, should be the key to the personalised content.

Can you explain a little more *why* that is?

Also, can you point to the best resource you know of that covers caching issues thoroughly and in depth?

Wednesday, February 28 2007 at 8:46 PM +10:00

Geoffrey Wiseman said:

I'm not sure if I understand what you're suggesting as the alternative to killing cacheability with authorization headers.

If your resource is secured, and requires authentication in order to be retrieved, then authorization must be checked before a resource is returned, even if that gets in the way of your caching strategy, no? How does using cookies (or not) really affect that?

Saturday, July 7 2007 at 1:50 AM +10:00

Alejandro Atienza said:

Mark,

i disagree with your assertion that personalisation and authentication are orthogonal; If it were the case, then on a random webapp an anonymous user would have access to your personalized representation, without authenticating as being you - i do not know if there are webapps implementing that functionality, but neither i have come across one of them nor i believe there is value there.

On the other side, i support your idea that using only one method is a better solution - at least on most of the cases.

The ideal solution would be a method to mark exactly what parts of a page are not cacheable - perhaps to an html-div level. The problem we are actually dealing with is that an html document is not as fine-grained as we could get. As Jonno says, you can cache images and .css, but you can't cache the left menu or the header of your documents without caching the rest - well, you may use frames, but hopefully you won't.

Tuesday, May 6 2008 at 1:32 AM +10:00

Mark Nottingham said:

Ajejandro,

It depends on the app. There are certainly cases where you want to share your data or your view of data with others, and that deserves its own URI. Likewise, in the back-end systems that compose those personalised views, personalisation data deserves its own URI too -- the mantra that "personalised data is uncacheable" has been proven false.

That said, of course there are cases where you want to tie personalisation and authentication; I'm just not happy when tools and protocols force you to conflate them.

Cheers,

Wednesday, May 7 2008 at 4:44 PM +10:00

Alejandro Atienza Ramos said:

Mark,

Completely on your side when you say that your particular data deserves a new URI. But, as I understand it, if it has another URI then it has been not personalised; it is another view of the resource. That is precisely why it deserves a brand new uri.

A uri is personalised, IMHO, when by means of logging in the same uri has different content among users. That kills cacheability and orthogonality.

That was the point i was trying to make on the previous post. Anyway, if you look carefully, you talked about personalisation and authorization orthogonality, whereas I replied talking about personalisation and AUTHENTICATION orthogonality, thus rendering my previous post fundamentally flawed on its premises. I was talking about something different, so I'm sorry.

Wednesday, May 28 2008 at 1:17 AM +10:00

Creative Commons