The Problem With OpenID
Flow|State has an excellent semi-rant about how poor the user experience is when using OpenID - both signing up and logging in. In particularly the question of what happens to all your accounts when your OpenID provider disappears is a particularly good one.
It so happens that I was looking into this just today since I needed a user friendly but secure authentication mechanism. OpenID seemed like a natural choice since I was effectively starting from scratch anyway, why not use a standard? The main problem I had with OpenID didn't really come through clearly in the Flow|State article though - OpenID requires users to log in twice. The first log in requires them to enter a URI, the second log in requires them to enter their password (or in some cases a username and a password). It's bad enough that most URIs are much longer than most usernames or even email addresses, but there's actually a page reload between the URi and the password. When was the last time you saw a webapp display the username and passwords fields on separate pages?
You can do a lot to make things easier on users of OpenID, but the whole protocol is based around the idea of having an extra page load between the URI and the password. You can avoid the problem sometimes if the OpenID provider's session hasn't expired yet but you can't have those sessions hanging around too long or they become a security hole.
So in the end, the best thing we can do is to ignore OpenID and use the old fashioned username and password per site. If we want to have a consistent online identity, provide a way to set your homepage URL and link to it where ever the username appears. You can still impersonate people but OpenID doesn't really stop that anyway - worst case, use OpenID just to verify that the person's homepage is really theirs.
August 17th, 2007 at 7:12 pm
There are a few good answers to “what happens if my OpenID provider goes away”:
1. If you’re forward thinking, you’ll use your own domain name as your OpenID and delegate it to a provider you trust. If that provider goes away, you can switch the delegation to point at someone else. Of course, this only works for the technical elite.
2. Smart OpenID consumers will allow users to associate more than one OpenID with their account (and also set up a regular username and password if they want to). Then if one of their providers is unavailable they’ll still be able to log in. This is extra hassle, but it’s worth it for really high value accounts.
3. The most realistic option: provide a “my OpenID isn’t working” link which acts exactly the same way as “I’ve forgotten my password” - it emails you a magic URL that signs you in; once you’re signed in you can add a different OpenID.
“So in the end, the best thing we can do is to ignore OpenID and use the old fashioned username and password per site.”
Completely disagree (of course I would…) - the best thing to do is to provide both, and make the OpenID part less prominent than the regular username/password signup. That way the majority of your users don’t have to worry about the scary new technology, while the small percentage who want to use OpenID will be able to.
When 37 Signals launched Highrise 9% of their signups were through OpenID; that’s a pretty healthy proportion users you’ve just made happier.
August 17th, 2007 at 7:33 pm
[...] original here: The Problem With OpenID Identity [...]
August 17th, 2007 at 9:02 pm
Simon,
9% of users isn’t a particularly significant amount given that most of those wouldn’t be unhappy if OpenID wasn’t available. The bottom line is that the OpenID sign in process is worse for users than having separate logins for different sites - particularly given the myriad of tools that remember passwords these days. The concern of your OpenID provider disappearing is obviously surmountable but is a problem for non-technical users. My main concern though is the user experience with logging in - it’s very suboptimal even for technical users.