There are several problems with using HTTP auth as a replacement for login forms. The biggest problem, perhaps, is that it's mutually exclusive: A resource is

There are several problems with using HTTP auth as a replacement for login forms. The biggest problem, perhaps, is that it's mutually exclusive: A resource is either protected by auth, or it isn't. There is no room in the spec for pages that change their meaning depending on whether you are logged in or not. Of course, one could argue that "logged in" pages should have different URLs, eg., /logged_in/*, and just use auth for those. The problem with that approach is that if you go to any resource not within that URL namespace, such as the front page, auth isn't necessarily sent by the browser, and so you can't know if the user is logged into the other parts of the site. Nor is there anything that supports the notion of "login sessions" -- once you're authenticated, you can't un-authenticate, as far as I know. We actually have a payment provider (DIBS, a Scandinavian company) that uses basic auth for their admin login. The only way to log out of their admin, such as in order to log into a different account, is to clear the browser state. And lastly, the login popup that browsers currently provide for basic auth is poorly implemented and altogether too simple. There is no way to ask for password recovery, for example, and there is no way to provide a signup button.