I think everyone has felt some time or another the frustration of having to deal with multiple passwords for the different sites you have signed up to. Which often leads to forgetting your password for this or that site, and having to regenerate it about every time you go to sign in to the site and you get a message like “Sorry, this password doesn’t correspond with this user account” ARGGHHHH!!! I was 100% certain that was my password!
One solution is to tell your browser to remember your login information for you, so that when you are presented with the login screen, you already have your username and password filled out for you. Well, though this could be a solution on a completely private computer, it however would expose your personal data if using a shared computer or if your private computer falls into someone else’s hands. So it probably ain’t the best solution. Another solution would be to have a place where you write down all your usernames and passwords for all the websites you have registered to, which though a little bit safer than the previous method, is still not 100% fool-safe and is also a big pain in the neck…
Well, to overcome this limitation some smart people started coming up with a solution that would let people sign into different websites with the same “credentials”, or rather with a “trusted provider”. This new protocol was named “OpenID”, and it certainly was a breakthrough idea at the time, especially since it was also an open-source technology. It never did become really popular among the general public though, because it wasn’t intuitive enough. But still it opened the way to the “single sign-in” experience. A lot of the big providers do use OpenID though even though you may not realize it. If you have a Google account, you have an OpenID account. If you have a WordPress account, you have an OpenID account…
Then the “big provider” era started. If lots of people haven’t heard much about “OpenID”, they probably have heard of Google, of Facebook, of Twitter… If they haven’t, they’re probably not the type that go onto the web too often or that sign into websites anyway. If an email address has already been verified by one of these big providers, we can pretty much trust their verification, so why not let someone sign into a website using an authentication mechanism from a big provider that tells you that yes, this email has been verified. That way people that use credentials often for Google or for Facebook and probably remember those credentials, don’t have to make new ones to sign into your website, they just sign in with their Google or Facebook account and there you go.
Well, this “account provider” solution has worked fairly well in the past few years, especially since the web has been becoming more “social”, this way of signing in with trusted providers was also a way of signing in with the “social container” providers, and opened up possibilities to making your own website more socially interactive, or making it interact with those social containers, giving your website more publicity, making a visit to the website more interactive and interesting and socially involving…
Well, that did seem a good solution, and is still used quite a bit. But it does have some drawbacks too. For one thing, the developer API’s put out by these social containers tend to change quite often. Which means that a webmaster has to continually change the coding for his sign-in mechanism, trying to keep up with all the API changes from these different social containers. And for another thing, every social container makes it’s own API with it’s own mechanisms, that although quite similar do have each their own specific flow. Which means that e webmaster has to account for the different authentication mechanisms provided by the different social containers or account providers. Sometimes the headache can be taken away by third parties who offer to deal with all the authentication mechanism codings for the different containers. But this has its drawbacks too: you have to trust the third party who is taking into their own hands your website’s registration and sign-in mechanism, and thus is potentially monitoring your users personal profiles… And if the third party has some downtimes? You may not have a login mechanism available on your website because of the third-party’s downtimes… And then last but not least, utilizing this kind of authentication mechanism, with or without a third-party, does tend to bog down the initial loading of your website, because it’s making all kinds of calls to these social providers, downloading their javascript API’s and such. And even though a lot of this javascript loading is supposed to be asynchronous, so it doesn’t slow down the loading of your webpage, in my own experience there was always something that was slowing it down (and you can actually see the status bar of your browser hanging on something like “trying to connect to something.facebook.com…”).
So we do have some interesting new technologies and some interesting advances in the way people interact with websites and with each other on the web, but these new advances still have their drawbacks. How do we deal with these drawbacks?
Well I just discovered a new proposal by the Mozilla team, which overcomes a lot of the aforementioned problems. It’s a new authentication mechanism initially called BrowserID, now called “Persona”, which let’s you authenticate your email address with this service, and once authenticated let’s you sign in to any website using this service without having to remember a password every time. No more headaches for coding the authentication mechanisms to several different social containers, no more page bogging with several javascript downloads from several different social containers… If you still want to have social interactions on your website you can still use all the social container API’s that you want for that, but your login mechanism has just been greatly simplified. And if different web browsers start adopting this new technology, it’ll probably make this authentication mechanism so much easier for everyone.
You can find more information on this here: http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in
and here:
https://developer.mozilla.org/en-US/docs/Persona
You can verify your email for usage with BrowserID here:
https://login.persona.org/
If you use wordpress, there is a BrowserID plugin which will enable BrowserID (or Persona) authentication on your WordPress website: http://wordpress.org/extend/plugins/browserid/.
I just installed it myself (I also contributed an Italian translation), and it couldn’t have been easier. I got rid of Janrain and am using BrowserID instead, and suddenly my website is like ten times faster. Plus I don’t have to worry about third-parties standing in between and dealing with my users data.
Be First to Comment