A Modest Proposal for Improving Website Authentication

May 2013  |  Status: Second Draft

What about a new HTTP header that describes the canonical way to authenticate with a website? For example, the following would tell a browser to send a secure POST request with two fields:

Auth-Spec: type=plain; action=https://www.example.com/login; method=POST; fields=email,password

A “login” button, when clicked, would generate the prescribed HTTP request and then reload the current page. The button would be provided by browser plugins at first, and included in all browsers by default after a while. Any cookies involved would be handled by the browser as usual. Variable names, data formats, and field names should be standardized by W3C. Probably restricted to the same domain for security, with exceptions managed with Access-Control-Allow-Origin or similar.

Having a spec like this would help password managers like LastPass, KeePass, and 1Password — and even browsers themselves, if they ever stop trying to promote third-party identity providers — manage per-website login credentials more effectively and reliably. No need to copy and paste passwords, no need for complicated heuristics to guess the meaning of form fields on ever-changing pages, no need for annoying “Log in with <something you’ve never heard of>” messages, no need for redirects back and forth, and no need for third parties to get involved at all.

Best of all, the API would be backward compatible with virtually every existing login system, since websites can simply report their current login URL and field names. We could even compile a list of defaults used by popular CMSes like WordPress and Drupal, so that any website that uses one of them would be supported out of the box.

When you’re in the business of implementing a login system, your ultimate competitor isn’t Facebook or Twitter. It’s the good old email-and-password login system that everyone is used to. You enter your email address, select a password, and you’re in, without ever leaving the signup page! If your UX has any more steps or redirects than that, you’re doomed. (Update: see what happened to OpenID and Persona?) By building on top of the familiar system, this scheme avoids doom.

The scheme would also be forward compatible (thanks to the type variable) with any new login system that might be introduced now or in the future, e.g. something based on PKI, or even your favorite third-party identity provider if we can agree on a standardized way to describe its authentication API.

Next step: come up with a similar spec for creating accounts and updating usernames, e-mail addresses and/or passwords. That would allow password generation and rotation to be completely automated, eliminating the need to use easy-to-remember passwords like “password”. Finally, we might invite Mozilla et al. to act as “zero-knowledge” storage services (like they already do with Firefox Sync) for an encrypted blob that contains all our randomly generated authentication tokens. You know, just in case your computer “crashes”, or if you want to log in with your iPad too.

Websites publishing standardized APIs. Users in complete control of their data and of their interaction with individual websites. Extremely simple UI. Fully synchronizable across devices. Easy to implement in the vast majority of existing websites and open-source apps. What could go wrong?

EDIT: Come to think of it, the <meta> or <link> tag might be more appropriate for this purpose, although I do like the idea of good ol’ HTTP authentication “done right”. I also considered using a DNS resource record (like SPF and DKIM), but HTTPS is more secure.

Please use this HN thread for comments.