Why It's Worth Fixing HTTP Authentication (and How to Do It)
What's Wrong With It
HTTP authentication (which I'll refer to as "httpauth") is useful when you want to quickly control access to something; you only need a few lines in your web server's configuration file to get it set up.
Unfortunately it's not good for much more than that, due to the terrible interface that every browser I've ever used has somehow settled upon. This interface presents three major problems:
First, most sites want to give the user the option to log in even if the page they're looking at does not strictly require it. Httpauth supports this, but browsers don't.
Worse, browsers throw up an authentication dialog as soon as they encounter a 401 Unauthorized response, without any context. If the user does not have an account, or has forgotten their password, their only option is to "Cancel" the dialog (to which the site's response is usually a frightening, uncustomized Unauthorized page).
Finally, once the user is logged in there's no obvious way to log out. Closing your browser will generally log you out, but this is hardly obvious.* This is easy to implement on the browser side - simply stop sending authentication data to a site after the button is pressed.
(I'm not the first to observe these problems (1, 2, 3). Bookmooch seems to have worked around them, but it's still far from perfect despite their efforts.)
Why It's Worth Fixing
But why bother? These days we use HTML forms and cookies for authentication on anything that matters, and it seems to work. Isn't httpauth an outdated technique, incapable of providing the rich authentication experience that today's users demand?
Well, no. Httpauth is perfectly capable; in fact it is preferable to cookie-based authentication in several ways:
- it can be more secure than HTML forms when SSL is not available. Digest authentication only sends hashed passwords. Servers can trade system resources for immunity to replay and session hijacking attacks (see section 4.5 of RFC2617).
- it can be completely stateless; multiple servers running the same site don't need to share a session store when Basic authentication is used.
- it simplifies caching. Responses to unauthenticated requests are cached normally, responses to authenticated requests go uncached.
- it works well with AJAX and with automated clients. Do you really need separate authentication mechanisms for your front-end and for your API?
As a bit of a purist, I think the best part is that your authentication layer can be completely separated from the rest of your application. You shouldn't need to clutter your interface or your code with authentication trivia. It's a classic example of code reuse; we're extracting an incredibly common pattern and moving it so that we don't need to recreate it every time we use it.
But there's not much point if we have to confuse and scare users to get these things. What to do about that?
How to Fix It
The slide-in toolbar (apparently called an infobar) that browsers have adopted provides a solution. I've made some mockups of what it could look like (please excuse the programmer art).
The browser would notify the user that they can log in without interrupting their browsing:
The bar sits there quietly waiting for them to log in. If the user requests something private, then the server sends back a 401 Unauthorized. This would need to be something friendly that allows the user to create an account, reset a password, etc.
When the user is logged in they would see something like this:
I'm sure these can be improved upon. Some kind of immediate user feedback is still required for requests that happen in the background (i.e. AJAX). Browser real estate is precious and I wouldn't want to look at that on every site that I'm ever logged into.
Conclusions
Writing the authentication infrastructure for a web application is not difficult, but it's still more work than letting some standard component do the work. The unhelpful UI the standard component has been given is the only reason we can't do that now.
My proposal is very similar to at least one that has been suggested on Bugzilla; the long time that one has been ignored is not promising. I've looked into implementing this myself, but - to be frank - Mozilla's codebase terrifies me (please contact me if you have any guidance).
Coordinating big chunks of code is tricky. Coordinating big groups of people working on big chunks of code is trickier, but if we can't get something as obviously broken as this fixed, then I fear for the future of the web.
*: Some (most? all?) browsers forget credentials for a site if the site sends them a 401 Unauthorized. Websites could provide a "log out" link that always 401s, but this is awkward.