It seems that folks at Quora don't like the OpenID even going as far as claiming that:
OpenID is the worst possible "solution" I have ever seen in my entire life to a problem that most people don't really have
Sounds pretty harsh, doesn't it? Personally I think it's all bunch of bollocks! I think problem does exist and OpenID is part of a solution. Fortunately Stack Overflow community, which opinion I highly value, has not yet ruled out the OpenID. In this post I intend to revisit the 'problem that most people don't really have' and take a fresh look at OpenID-based implementation.
A common problem
I believe that nowadays average, day-to-day Internet user has to find a method to store tens, sometimes hundreds of authentication details. Most resolve to re-using the same password(s), using a password manager or using a "method" for password generation. Either way when presented with a registration form for a new service, users are reluctant. They start to ask questions: "Do I really need to post that opinion online?", "Are they going to send me spam?", "Can I be bothered to remember another login/password combination", "Do I have time to wait for the confirmation email?" etc. This is unpleasant for a first-time visitor who wants to quickly see what is your service about. It also lowers your conversion rate. Various implementations of a federated login mechanism have been devised or adapted as a solution to this problem and OpenID is one of them. While it might not be perfect it is a viable alternative to standard login/password combination, especially if used as part of solution and not as a solution on its own. And only if implemented right.
Doing it Right
To define what I consider right implementation I will first explain what's definitely should be avoided - a plain 'enter your OpenID' box is simply wrong. It's wrong because it's very confusing for users who are not familiar with OpenID. Average user probably already has an account with an OpenID provider and is not even aware of that! Major online service providers such as Google, Yahoo and AOL all can act as OpenID Identity Providers - if your visitor has an account with any of these guys, it means he already has an OpenID account. So let them know! Rather than asking for OpenID identifier, ask your visitor to log in with any of these providers.
I've already seen couple of examples of a good implementation of a federated authorization in the web and, despite of what people at Quora say, most of these make use of OpenID among other methods. I believe that SpringPad has got it almost right, the only thing I don't really like is the fact that they put so much emphasis on a classic login/registration and so little on the actual federated login capability. Personally I would make it more obvious that you don't really need to register. Also Stack Overflow implementation is not bad for more 'geeky' audience but forces users to register with some arbitrary third party provider if they don't have an OpenID or Facebook account which might discourage some potential visitors. Also there is no single sign-on between all Stack Exchange Q&A sites (you need to login to each of these separately), which is pretty disappointing.
My approach
I think that a decent implementation would:
- Offer access with multiple popular, respectable (also trustworthy) and recognizable providers such as Google, Yahoo, Facebook, Twitter
- Offer a fallback mechanism - alternative for those who can't or don't want to use social login
- Don't ask ANY questions or confirmation if user logs in with a third party provider. In particular don't ask to create an account.
- Be able to spot user that has previously logged in with another provider. Allow manual associations of additional third party accounts (i.e. user has logged in with Google, but wants to associate their Facebook with their profile)
- Explain why do your users need to use a third-party provider to login and what are the benefits
- Make a promise not to spam
I've been working on implementation that would meet the requirements listed above and as of today my code covers items 1 through 3 from the list above. I've setup a working demo and shared code on github so feel free to grab yourself a copy or even better fork me! - I would love to see this code brought to completion.