One of my side projects is a small, subscription-based business built around a website. Obviously authentication and authorization are concerns. I've built the application using Plack, so I have middleware to separate the interesting concerns of authentication, authorization, and database selection from the mechanics of the application itself.
(I can troll people like Aristotle and Stevan and even Miyagawa by suggesting that Plack middleware and inversion of control can have much more in common with each other than you might imagine.)
While thinking about authentication today, I decided that the login system could use a standard HTTP authentication mechanism where, instead of typing a username and password into a little form on a web page, the client should pop up some sort of authentication box as a prompt.
My business partner scowled and said "People find that scary."
The difference between returning the appropriate HTTP headers to prompt a client for authorization and returning an HTML page with a form to fill out is minimal on the development side. How about the user experience?
Is prompting for HTTP authorization less friendly? A login form—not a popup—exists in the context of a site. It can have links to register or to recover a forgotten password.
The cleanliness (the HTTPfulness!) of the authorization header still appeals to me, however, even as I recognize that it may put off a lot of people. Alternately, deep linking into the application could use authorization, while visiting the front page could use the login form...
... but perhaps this is a case where cleverness or theoretical purity is much less important than ease of use and clarity to customers.
I have to agree that the HTTP authentication may be "scary" but this is because this is how the browsers implement it. In theory they could display the authentication in a browser chrome frame instead of as a popup or something else, though you still have the register/forgot link issue. You could put them on your 403 error page, but unless the customer knows how to use the HTTP authentication UI, it will be a bit before they see the 403 page.
The biggest problem with HTTP authentication is that you can't log out. Forcing your users to close a browser to log out isn't the norm and could expose your users (and you depending on what kind of service it is) to security problems.
It’s such a lost opportunity that something like this never came to pass:
http://fishbowl.pastiche.org/2003/12/30/saving_http_authentication/
Michael is right. I think that HTTP Auth is great for geeks and for APIs, but lousy for normal humans. The non-integrated login form is scary (looks like something is taking over the browser!), and the inability to log out is huge. See PAUSE's notes on logging out for the gory details.
I've always wondered... why can't we use a form call to http auth... ugh.
Popup is generally a bad idea because it forces distraction. Solving that ridiculously requires a new major browser release.
The major problem of HTTP auth in terms of user experience is: site designers have no way to define the look and feel of that HTTP auth login form / dialog to match their site content. IMHO if CSS can be used to style the auth form, people probably would not have hated it. Many web services, for example, gmail, require login in their first page, there are margins where HTTP auth still work. However not being able to style the login form is really a big pushback.
Just imagine if the gmail login page is nothing but a login dialog says "Gmail credential required" -- without all those bullet items describe how awesome gmail is, no way to put some fancy mailbox size up-counting numbers... It would be so frustrated for gmail folks who want to make their first page looks awesome. After all that is the first impression for their users.
It probably does not scary users away (like zombies) but it will not be able to make users stay.