The mere presence of systems like OpenID, Facebook Connect and a host of other identity services on the web today is attestation to the fact.
Authentication should be a feature of the protocol, not something that relies on hacks like cookies. 99% of websites today rely on cookies for authentication for their websites, besides offering custom registration and login pages. This means the browser, as the user’s agent, has no clue of what is going on. A user is forced to manually track myriads of accounts, remember passwords for each of them, and remember what personal information each of them holds. Sure, part of the problem is solved by using password managers (like the one in-built into Firefox, or external programs like 1Password), but even these programs rely on heuristic algorithms to determine if something looks like a login credential or not. There’s no explicit way for web pages to tell your browser: “This is a login form, please fill in details of the user’s identity here” or “These pages are privileged, please give me the user’s identity”. Why is that?
Actually, there is such a mechanism: HTTP based Authentication has been a feature present since HTTP/1.0, but only 1% of sites actually use it. The reason for that is purely cosmetic, most browsers display a very bland modal dialog when it encounters a page that requires HTTP Auth, and sites are unable to customize that interaction. So, the technically right way to do things sucks from a user experience perspective, and websites started adopting alternate means. Someone discovered they could use cookies to store session information on the client, and the whole situation exploded ever since. As a programmer, I feel very sad when I think about the fact that instead of fixing the problem in HTTP/1.1, web-based authentication took the route it did and led to the mess we are in today.
However, I must also state that HTTP authentication doesn’t solve the entire problem – there is still the issue of users having to create an account for every site they want to be part of. This is because there existed no protocols to federate and provide decentralized authentication. That is, until OpenID and OAuth came about. Now we’re at this exciting juncture, and the browser is in a unique position to use these tools together to provide the user with an experience that is secure and easy to use. Every architect will agree that it is indeed a fun challenge to use the state of identity on the web today and make it into something awesome.
This is precisely what the Mozilla Labs team has been thinking about for a while now. Sometime ago, we added support for automagic one-click OpenID logins to Weave. We plan to spin that “feature” out into it’s own extension and build on it, something we call “Weave Identity“, part of the broader “Open Identity” initiative by the Labs. “Weave Sync“, the original extension, will just focus on the synchronization parts so we can tackle these two different problems separately.
So, how exactly are we planning on doing this? Take a look at an initial version of a document describing an in-browser “Account Manager“. We’ve also put up a WEP (which expands to Weave Enhancement Proposal, by the way) describing the raw form of a specification for automatic actions on websites, such as user registration or password changes.
Keep in mind that all of this is in its very early stages (pre-alpha); but that also means it’s a great opportunity for the community to get involved! What are your thoughts on Open Identity? Use the discussion tab on any of those Wiki pages, start a thread on the Mozilla Labs group, or simply leave a comment on this blog entry, and chip in – we’d love to hear from you!
It always will be broken until multi-factor identification is the base standard.
Something you know: password or tune or rhythm
which is used as the salt for
Something you are: biometrics
which is used to activate
Something you have: yubikey or smart phone
Although this combination is still vulnerable to being mugged by a telepath that also cuts off your thumb.
Anant, I used to have the same view on HTTP Authentication until I spoke to people building sites which have non-trivial security requirements. They aren’t in a position to use HTTP Auth because it doesn’t include a session timeout and doesn’t allow the server to invalidate the session and require the user to re-auth. This is important for secure sites given how computers are shared (or simply left unlocked when people go for a coffee). With HTTP Auth, once I’ve logged in to a site, that access is valid until I restart the browser.
Hopefully going forward we can find solutions which are technologically nicer than html forms+cookies, but that also leave the server in enough control that secure sites feel comfortable using them.
David
Regarding HTTP Auth, you forget the fact that it always sends the password and username as plain text with every request to any page, which is really not the best idea. Most plain HTTP sites at least only need you to send this plaintext password once per session…
@David: What you describe is the *current* state of HTTP Auth, and that is what I say in my post: we should have fixed it in HTTP/1.1 by adding support for “logging out” and other such things needed in an authentication model. Instead, we decided to adopt the cookie approach which I think is ugly, messy, and just doesn’t feel right
@Robert: That is true for HTTP Basic Auth, but HTTP Digest Authentication (http://en.wikipedia.org/wiki/Digest_access_authentication) which is also part of the spec doesn’t require the password to be transmitted in plaintext.
> Authentication should be a feature of the protocol
No it should not: http://doc.cat-v.org/plan_9/4th_edition/papers/auth
Including auth as part of the protocol has bee a mistake over and over again, it is inflexible, insecure, and just a pain.
As for the rest HTTP auth is a joke, OpenID is an insanely complex nightmare, and OAuth is a few magnitude orders worse than that.
Add something like factotum to firefox, and there might be some hope that perhaps some day the auth problem in the web might be solved, but I’m not counting on it.
OpenID and human nature means that most people will use the same URI for most sites, making it easy to track them and thereby eroding their privacy. An alternative is to disclose your identity provider, but not your identity. Essentially, you get your identity provider to provide credentials bound to the session id. However, a bigger issue remains, how do we avoid websites requiring the use of just a tiny handful of giant corporate identity providers. Certificate chains could provide a solution, e.g. enabling a website in Nebraska to accept the Swedish government as an identity provider. This raises significant social issues on an international scale.