There are many advantages to HTTP Basic Authentication, but despite these advantages, web developers have turned almost exclusively to using cookie-based authentication because of some limitations in how HTTP Basic Authentication can be implemented. Until recently, there has been no way to for developers to control the login form nor provide a way for users to log out.
The advantages of using HTTP Basic Authentication are easier integration. In particular, mod_auth_mysql for Apache makes it possible to easily password-protect areas based on usernames, passwords and roles stored in a central authentication database. The main alternative for authentication, cookie-based authentication, provides a higher barrier for integration projects.
Despite the integration advantages, most web developers use cookie-based authentication because they want to control the user experience of logging in. When logging in using HTTP Basic Authentication, the browser shows a login prompt. Developers have no control over the look of this login prompt; therefore, there is no ability to add useful information like links to retrieve forgotten passwords.
After several unsuccessful login attempts, HTTP Basic Authentication redirects to a 401 error page. Only at this point can developers provide further instructions to assist the user. And with some browsers (ahem.. Safari), the 401 page will not be rendered if the user cancels their login attempt.
Once someone logs in, there is no way to log them out short of quitting the browser. Apache’s FAQs provide the best explanation of the limitation:
How do I log out?
Since browsers first started implementing basic authentication, website administrators have wanted to know how to let the user log out. Since the browser caches the username and password with the authentication realm, as described earlier in this tutorial, this is not a function of the server configuration, but is a question of getting the browser to forget the credential information, so that the next time the resource is requested, the username and password must be supplied again. There are numerous situations in which this is desirable, such as when using a browser in a public location, and not wishing to leave the browser logged in, so that the next person can get into your bank account.
However, although this is perhaps the most frequently asked question about basic authentication, thus far none of the major browser manufacturers have seen this as being a desirable feature to put into their products.
Consequently, the answer to this question is, you can’t. Sorry.
Because my company uses HTTP Basic Authentication, I’ve become very good at explaining why we can’t have a form in the web page for logging in and why we can’t provide a log out button.
A couple of years ago, John Keith (our CTO) and I theorized that if we could log the user into the same realm using credentials that were only valid for a single page that we could mimic log out behavior. We explored trying to set the credentials on the server, but found that this only worked in Apache 2.0.
Basically we hit a brick wall until a couple of months ago. Thankfully, the increased emphasis on web services has caused a resurgence in HTTP Auth interest. If you have a password-protected API, you can’t assume that the client will accept cookies. In fact, it is unlikely that the client will accept cookies so you have to find an authentication alternative.
We’ve been experimenting with a new technique that allows for both form-based HTTP Basic Auth login boxes as well as log out buttons. It works using AJAX to take the usernames and passwords from the form and pass log the user in via the XmlHttpRequest object.
A similar technique logs a user out by logging the user into a page with credentials that are only valid for that page. The user never truly logs out, but the effect is the same. Until the user supplies their original credentials, they will be unable to see anything other than the one page.
I’m pleased to say that we’re having some success with these techniques and are using them to solve a long-standing customer issue. Details on the technique we’ve been basing our development on were originally published by Paul James. I highly recommend taking a look at some of Paul’s other articles on RESTful implementations and HTTP caching.
If you’re using HTTP Basic Authentication, you should look into these techniques immediately. Your users will thank you for it.
hey, that’s actually a pretty cool strategy. my personal preference is cookie-based, but it’s good to know this if i have to use http auth.
(found your site by way of max)
The web is so incredibly broken. How reliable is this approach? what guarantees do we have that some web-browser will never break this approach?