After first reading about OpenID, I started looking for WordPress plugins to get it working on my site. There were ux issues with each of the plugins I tried. I planned to compare them here, but after some investigation I’m reluctant to recommend OpenID because of control, privacy, and especially security concerns. There is much work already in progress to address these issues. Below I’ll describe OpenID, discuss some of the down sides, and offer a few recommendations if you want to try it out.
What is OpenID and Why Use It?
OpenID reduces the number of logins a person needs to create and remember, making it possible to use a single ID to authenticate to many online services. The ID is any address that you can prove belongs to you (i.e. you can log in to it) and that is enabled with OpenID-related tags. OpenID describes itself as an “open, decentralized, free framework for user-centric digital identity.”
Getting and Choosing an OpenID
To log in using OpenID, you need an OpenID-enabled URI: a web address that is associated with you and which you can authenticate to. The following are each URIs I can use as my ID on any OpenID enabled site:
You may already have access to OpenID: Yahoo, flickr, blogger, technorati, and aol are just a few OpenID providers (IdP’s) who have made it possible for their users to use their account URI as an OpenID. If you don’t have an account with an OpenID provider, verisign, claimID.com and others provide IDs. You can also use your own blog or other URI as your OpenID.
Choosing your OpenID URI provokes questions about how you manage and connect your various online identities. The OpenID you use often becomes a live link to your OpenID URI, such as when you post a comment on a blog. When I use my meme online, do I want people to link to my blog, flickr, linkedin, facebook, del.icio.us, technorati, or somewhere else? Do I bring these presences together? Jeffrey Zeldman mused about online identity spread in his busy April 22nd post, The Vanishing Personal Site.
Using an OpenID
A growing number of sites invite authentication via OpenID login, such as technorati, 37signals, wikiHow, drupal, and many blogs.
When you log in with OpenID, the site you are trying to log in to puts a request to your ID’s URI. A couple of tags at your OpenID URI redirect the request to the IdP to verify that you own the URI. The IdP has you log in to your page to prove you are the owner and then confirms to the requesting site that you are the owner of that URI. Simon Willison offers a screencast of OpenID in action.
Control, Privacy, and Security
There are a few control-related issues with OpenID, the first being the longevity of your relationship with a 3rd party. If my ID is tied to a site where I maintain an identity (e.g. flickr, technorati), and eventually that site goes away or I stop affiliating with the site, I will have links and logins I created in the past tied to those accounts. Similarly, the site itself might fold. For increased control, you might choose delegation: using a URI you own, such as your domain, in combination with an OpenID provider. In this scenario your URI can be ‘permanent’ but you can switch IdP’s (OpenID providers) anytime. (Check out Sam Ruby’s tutorial on setting up delegation.)
A second control issue is security-related. Once you are logged in to a site through OpenID, your IdP manages login requests from that site, giving security control decisions to the IdP. This is risky in terms of both phishing and CSRF (cross-site request forgery) attacks.
Regarding privacy, your IdP processes all of your OpenID login requests, gathering a great deal of information about your activities. Whom do you trust with that information? Trust not only in that you believe they are not evil, but that their servers can not be compromised? You can use multiple IdP’s to spread out the knowledge about you to mitigate the tracking potential of a single IdP, but at some point this defeats OpenID’s promise of reduced sign-on.
In terms of security, there’s a plethora of discussion out there. (Check out Eugene and Vlad Tsyrklevitch’s great paper and the idcorner.org post on OpenID security.) In short, when you log in somewhere with OpenID, you are taken, ostensibly, to your IdP’s authentication page, but phishing could be at work, tricking you into providing login information to a 3rd party’s site. Why not just stick with a password manager on your computer?
Have you changed your passwords lately?
Is Trivial-Use-Only a Valid Recommendation?
I’ve seen the recommendation to use OpenID only for trivial uses, such as blog logins. If it gets hacked and someone can be you using your OpenID, then they can still be you on other OpenID-accepting sites. This recommendation is only useful if risking your identity associated with web posts is acceptable to you and only while the sites accepting OpenIDs remain trivial in nature (or until the phishing and other security issues are solved). If you decide to go with a trivial-use-only approach, I recommend the following: Create a free id at claimID or OpenID and delegate to your own URI for increased control. When you create your ID, use a strong password you only use for that ID, so that if it gets hacked, you haven’t given away the store.
Entering a URI (web address) for a username breaks login conventions: it is something to which people will need to become accustomed. The first time you authenticate with OpenID, it likely requires more steps than creating an account on the site requiring you to log in. (This is especially the case if you are not currently logged in to your IdP.) On mobile devices OpenID is unwieldy. Not only do you have to key in an entire URI, you’re far less likely to be surfing on a handheld and thus logged in to your IdP, so you’ll also need to log in to your IdP after keying in that long URI.
OpenID and Accessibility
Accessible implementation of OpenID requires more than a label and id on a login form. People who are new to OpenID need some explanation about what it is and that they may be sent briefly to their id provider’s website for authentication. OpenID login should be visually and semantically separated from username and password fields. Yesterday Clayton Lewis got me thinking about the wonderful accessibility opportunities in the realm of OpenID. Perhaps your OpenID URI will store information about your preferred minimum font size or a link to your alternate style sheet, making it easier to switch from browser to browser and computer to computer without needing to repeatedly enter these settings. What accessibility problems or promises do you see with OpenID?