I have this dream that one day we will see true interoperability between social networking sites potentially powered by OpenID. As part of trying to make this dream a reality I've been reading a lot about the pros and cons of implementing OpenID since a shared identity system is the cornerstone of any hope of getting interoperability to work across social networking sites. Here are some of the things I've learned.

The Problems OpenID Solves for Web Developers

There are two ways to approach using OpenID on your Web site.  The first way is to treat OpenID as a way to delegate user authentication on your site to another service. This means that you rely on someone else to authenticate (i.e. sign-in/log-in) the user and take their word for it that the user is who he/she claims to be. Some sites use this as the sole means of authenticating users (e.g. StackOverflow) while others give users the choice of either creating an account on the site or using an OpenID provider (e.g. SourceForge). The assumption behind this view of OpenID is that asking users to create yet another username/password combo for your site is a barrier to adoption and using OpenID removes this barrier. However this assumption is only correct if the OpenID sign-in process is easier for users than registering a new account on your site.

The second approach is to use OpenID as a way to give users of other Web sites access to features of your site that are traditionally only available to your users. For example, Google's Blogger has an option to enable anyone with an OpenID to comment on your blog. However Blogger does not allow you to login with OpenID instead you must have a valid Google account to create a blog on their service. In this scenario, the assumption is that asking users to create yet another username/password combo just to leave a comment on a blog or use some other feature of the site is too high of a barrier to entry but that same barrier to entry is acceptable for people who want to become full users of the site.

It should be noted that the second approach is actually why OpenID was originally invented but scope creep has made it become a popular choice as a single sign-in solution. 

The Ideal OpenID User Experience

As a Web developer, the main problem OpenID is supposed to solve for you is that it reduces the barrier to using your service. This means that if redirecting a user to an OpenID provider to be authenticated and then having them redirect the user back to your site is more complicated than a new user account creation flow you could build on your site then using OpenID will cost you users. The ideal OpenID user experience should be

1. Your log-in page gives the user a choice of OpenID providers to use to sign in
2. The user selects their OpenID provider from a list or enters their OpenID provider information
3. The user is redirected to a log-in page on the provider's site
4. User enters their credentials
5. The user is redirected back to your site and is now logged in

Even in this ideal flow, there is a chance you will lose users since you have distracted them from their task of using your site by directing them to another site. The assumption here is that the redirect->sign-in->redirect flow is less cumbersome than asking new users to pick a unique username and password as well as asking them to solve a Human Interactive Proof or CAPTCHA. This sounds like a fair tradeoff although I'm not aware of any published research results that back up this assumption.

However if the OpenID sign-in flow is any more complicated than the above steps then the risk of losing users increases significantly. Here is an example of how OpenID can cost you users taken from a post by Ned Batchelder entitled OpenID is too hard 

Earlier this week I visited yet another site that encouraged me to get an OpenID, and I decided I would finally cross OpenID off my list of technologies I should at least understand and probably use.

The simplest way to use OpenID is to pick a provider like Yahoo, go to their OpenID page, and enable your Yahoo account to be an OpenID. This in itself was a little complicated, because when I was done, I got to a page that showed me my "OpenID identifiers", which had one item in it:

https://me.yahoo.com/a/.DuSz_IEq5Vw5NZLAHUFHWEKLSfQnRFuebro-

What!? What is that, what do I do with it? Am I supposed to paste that into OpenID fields on other sites? Are you kidding me? Also, in the text on that page is a stern warning:

This step is completely optional. After you choose an identifier, you cannot edit or delete it.

(Emphasis theirs). So now I have a mystifying string of junk, with a big warning all over it that I can't go back. "This step" claims it's optional, but I seem to have already done it! Now I'm afraid, and I'm a technical person — you expect my wife to do this?

How many users do you think start this process and complete it successfully? Now how many of these users would have been lost if the site in question had replaced their OpenID usage with a lightweight account creation process similar to that used by reddit.com which only requires username/password and solving a CAPTCHA?

This is food for thought when comparing the costs and benefits of adopting OpenID.

The Risks of Using OpenID

There are lots of commonly voiced criticisms about OpenID, a number of which are captured in the blog post entitled The problem(s) with OpenID by Stefan brands. A few of the complaints are only interesting if you are a hardcore identity geek while others are of general interest to any Web developer considering adopting OpenID. Some of the key criticisms include

• Susceptibility to Phishing: The argument here is that the growing popularity of OpenID will train users into thinking that it is OK to enter their credentials on a "trusted site" after following a link from another Web site. However given that this is how phishing works it is also training users to be more susceptible to phishing since any random site can now claim to be powered by OpenID when in truth it redirects people to http://www.example.com/phishingattempt/yahoo.com/login or some similarly malicious URL.

  Given that we live in a world where worse practice of Please Give Us Your Email Password is now commonplace and the best solution people have come up with for dealing with it (OAuth) also utilizes browser-based redirection, I'm not sure this is a fair criticism against OpenID.

• Identity Providers May Be Lax about Validating Users: When you outsource user authentication to an identity provider via OpenID you are trusting that they are performing some minimum level of user validation to keep spammers and bots out of their service. However there is no requirement that they do that at all nor is there any minimum standard that they have to meet. A year ago, Tim Bray posted an interesting thought experiment where he pointed out that one could create an identity provider that "successfully authenticated" any user URL you provided it with. You can imagine what kind of fun spammers would have with such an identity provider on a site like StackOverflow.

• Identity Providers May Recycle Identities: A number of large email service providers like Yahoo! and AOL have decided to become OpenID identity providers. Email service providers typically recycle abandoned email accounts after a set period of time. For example, if I don't sign-in to my dare@example.com email address after three months then all my data is wiped and that account joins the pool of available email accounts. What happens to my accounts on other sites where I use that email address as my OpenID? Does this mean that the next person to use that email address can log-in to StackOverflow as me? Maybe…it depends on quality of the identity provider.

• Privacy Concerns: Delegating user authentication to another service means you are letting this other service know every time a user logs in to your site and often times what the user was trying to do since you pass along a return URL. Depending on the sensitivity of your site, this may be information that you would rather not leak about your users. Then again, most Web developers don't care about this given how much information about their users they let Web analytics firms and advertising providers track.

White Lists are Key

The bottom line is that accepting an Tom, Dick and Harry as an identity provider on your site is probably a bad idea. User authentication is an important aspect of an online service and delegating it to others without vetting them is not a wise given how widely the user experiences and the policies of various identity providers can vary. Developers should evaluate OpenID providers, then select a subset those whose policies and sign-in experience is compatible with their goals to avoid the risk of losing or alienating users. 

Now Playing: The Game Ft. Ice Cube - State Of Emergency