#+TITLE: Site-Controlled HTTP Authentication UI * Motivation HTTP Authentication is significantly less fundamentally broken than cookie-based authentication. And, while I've been meaning to write this up for years, the recent release of [[http://codebutler.com/firesheep][Firesheep]] has brought the issue to the fore once again. [tdm] explains many of the issues involved, so I'll just summarize briefly: 1. The browser UI for HTTP Authentication sucks 2. Websites want to control that UI A natural consequence of these two things is that no sites use HTTP Authentication, and browser vendors don't bother to make it not suck. This is my proposal to make HTTP Authentication website-controlled, while remaining backwards compatible with form-based authentication in browsers which do not support the proposal. * Proposal ** HTML Forms Login forms need add only a single class to their
tag: "http-authentication". This class signals to the browser that it should use the "username" and "password" fields for this form as the corresponding fields in HTTP Authentication. These fields MUST NOT be submitted with the rest of the form when using HTTP Authentication. Any additional information necessary to perform authentication (nonces, etc.) should be pulled from the standard WWW-Authenticate headers. Any fields in the login form not understood by the browser as part of a login request MUST be submitted as normal for the provided form. ** Changes to RFC 2617 WWW-Authenticate headers MAY be sent along with 2xy and 3xy responses to indicate that a page supports optional authentication. Vary: Authorization and appropriate Cache-Control headers should be used when doing so to allow caches to work properly. A browser using form-based HTTP Authentication MAY use data acquired from a WWW-Authenticate header sent with the form to authenticate itself without the additional round-trip that would otherwise be required. ** Stopgap Measure To use this feature before sites implement it, sites may use JavaScript techniques along the lines of [peej] to silently force the browser into HTTP Authentication. I've set up a (very rough) example at http://httpauth.kepibu.org/login.php. The source code contains additional comments relevant to implementers of the stopgap measure and can be fetched as a darcs repository via the command : darcs get http://repo.kepibu.org/httpauth/ ** Working with the Stopgap Measure in Browsers that Support This Spec Assuming sites implement the stopgap measure, and browsers later introduce native support for this specification, it becomes important for browsers and sites to communicate with each other about who is in charge of handling the form-to-http-auth transition. As someone who loathes the number of sites that fall apart with JS disabled, it is tempting to simply say browsers should refuse to fire JavaScript events on the submission of http-authentication forms. However, since sites will almost certainly be doing other things in the JavaScript for those forms, that is not a viable option. Instead, it seems prudent to utilize the DOMImplementation hasFeature function. Thus, I propose a feature name of "HTTPFormAuth" and a version of "1.0". ** Logging Out Forcing logout for users is left to a future version of this specification. See [tdm] for ideas. * References * [tdm] :: Weaning the Web off of Session Cookies (Timothy Morgan, 26 Jan 2010) http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf * [peej] :: HTTP Authentication with HTML Forms (Paul James, 03 Feb 2006) http://www.peej.co.uk/articles/http-auth-with-html-forms.html * [ha] :: HTTP Authentication: Basic and Digest Authentication (RFC 2617, Jun 1999) http://tools.ietf.org/html/rfc2617 * [w3] :: User Agent Authentication Forms (W3C Note, 03 Feb 1999) http://www.w3.org/TR/NOTE-authentform * flyspell :noexport: LocalWords: UI LocalWords Firesheep peej authentform html tdm Login http login LocalWords: username nonces pdf JavaScript auth JS natively logout xy darcs LocalWords: php