Mozilla recently presented a new approach to authentication, using the browser as an active agent in the authentication process for increased usability and security. At a first glance this looks very similar to openID and, some say, OAuth and while reading about it I've seen a lot of confusion among these different protocols. And with good reason, because although the all are different and solve different problems in different ways the also all behave very similar.

If you are tech savvy and already know how openID and OAuth works - please just skip the two first sections.

openID

openID was the first player in the game and dates back to 2005, and it allows users to identify themselves to services by authenticating using a URL they controlled. In a real world implementation a user can authenticate to a website (like blogger.com) by entering the URL to his/her own website or openID provider (like Google). The website the user authenticates to does not need to have and store e-mail and passwords for every user in their system - which is a good thing considering the amount of compromised databases with weakly hashed passwords we see on a weekly basis today.

So, did openID succeed ? The goal of openID was to create a common decentralized login for the web, and measured by that standard it clearly failed. And a quick lookup on google trends shows a decline in interest in openID in the last couple of years.

A lot of the big players like Google, Facebook, Yahoo, AOL etc where all quick to implement themselves as openID provides, giving people the opportunity to use their service as "the global login", but non of them actually accepted openID to login to their service. Neither did any other sites except enthusiasts and a very few exceptions.

Another thing I personally was very excited about when openID was introduced for the first time was: "If I can authenticate by using my own blog I do not have to hand out my e-mail to every single site on the web." However, it quickly became clear that sites did want my e-mail in order to allow me to sign up, so even if they supported openID and doesn't need my e-mail in order to validate my authenticity they did require it in order for me to sign up. I should note however that many openID providers like myopenid.com makes it very easy to create different "profiles" where you easily can give sites fake e-mail accounts.

Did openID succeed anywhere? openID succeeded right here, on this site. Individual developers or small groups who have a website (or any other service) and need to authenticate themselves without creating a large authentication system. I use openID here on my site to login and edit content. I do it because it was extremly easy to implement, and I do not need to think about storing my credentials in a secure way. Furthermore, because I (internally) use google as my openID provider I am more or less always automaticlly logged in which is very convenient.

OAuth

OAuth is openIDs cousin. Where openID allows you to authenticate yourself to an application, OAuth allows one application to authenticate to another and access certain data from it. The protocol is similar, but the usage it very different.

Did OAuth succeed ? Absolutely, and it is used widely on a lot of sites everywhere, every day. Every time you give a webpage access to another. Like linking Google Buzz to Twitter, Gives an Facebook application access to some of your data or giving any other application any kind of access to your Twitter account. When used correctly OAuth the de facto way of linked webservices together.

But only when used correctly. OAuth is not intended for authenticating users. Twitter realized this when they tried to push OAuth as the only way for apps to interface with twitter. Because OAuth relies on a shared secret key between the two parties this key need to be kept - well, secret. This is possible as long as the two parties are webservices where the code is hidden on the server side, but when OAuth is used as authenticating mechanism in a desktop client the secret key lives on the users computer and if tech savvy enough this creates a gaping security hole where the user can retrieve the secret key, and access all the resources other users might have given the same client. This means if Obama is using TweetDeck to tweet, and I reversed engineered TweetDeck I would be able to tweet as Obama.

The problem still exists, but twitters terms of service requires that you somehow hide your token inside you application. This is far from perfect, but until know twitter seems to have avoided any major scandals.

BrowserID

BrowserID is the new kid in the block, and it much like openID allows users to identify themselves to third parties. A detailed description of how it works can be found here.

Basically BrowserID works much like openID, but instead of proving the ownership of a domain the user is required to verify the ownership of a e-mail address. This can either be done directly at the mail provider or at a so called "secondary provider" who verifies it by completing the traditional receive e-mail and click the link loop. When the user has proven his ownership of the e-mail the browser is handed a certificate for the e-mail and update its internal keyring.

When the user later want to log into a website using that e-mail address the browser just sends the certificates public key to the website which then validates it with the e-mail provider. If everything matches the user is grated access to the website.

I was initially quite skeptical of the idea of browserID, but after looking into it it seems like an evolution of openID which possesses some usability advantages.

1. First of all - and I know this has been stated a thousand times elsewhere - it is easy to understand for new users. I was comfortable identifying myself with a URL with openID, but most users on the web does not have a website, or find it intuitive that the should user something like https://www.google.com/accounts/o8/id as their "username".
2. You do not need to setup anything. With openID you could use your own homepage as identifier, if you inserted the correct lines of code on your homepage (of you even had one). This may be an easy task for some people, but completely impossible for most.

but it also keeps all the advantages from openID

1. It is decentralized
2. The method of authentication is not specified by the spec. It is up to the browser if the want to use a simple password or advanced biometric iris scanning in order to unlock your keyring.
3. It allows for multiple identities. At first I did not like the idea of making my e-mail address my primary identity, since I do not want to hand it out to every site out there. However, as I said in about openID that is already pretty much the case today and there is nothing in the browserID spec that says the browser only can handle one e-mail - actually it is designed to work with more than one. This means that you can use your primary e-mail for sites you trust, and a fake e-mail for all the other sites.

The only disadvantage I can see is:

1. It requires scripting to be enabled. Without scripting it becomes impossible to tell the browser to generate the required key pair. I know that scripting is pretty much a de facto standard on the web today, but a lot of users turns it off and try to live without due to security concerns (and for a good reason).

As I said I was initially very skeptical about browserID since I was a big supporter of openID. However, after thinking about it for a couple of days I have come to the conclusion that openID most likely wasn't the right solution for the average internet user, while browserID might just be what we need in order to get away from the thousands and thousands of different authentication systems we have today.

Of course nobody knows if browserID is going to succeed or not, but it does have some potential - I think. Only time will tell.