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.