August 25, 2010: Gonna channel JWZ a little bit here.

I've never used OpenID myself. I understand its appeal, how as a user you can maintain just one user/pass for a handful of sites. I have literally hundreds of logins for stuff, so anything that cuts that down is great. I just never had the opportunity to use it, because most sites still suck and want their own special user/pass. So I'm making a new site, no logins yet, and I want to store no passwords. I'll use OpenID (and maybe additional providers) for my authentication provider. Great.

First, nobody knows how the hell to use an OpenID, since it's nowhere. The solutions provided by the community are poorly conceived, and ultimately make the task of logging in harder. Look at their site on how to use OpenID as a typical user. When have you ever seen that field? When? It's completely foreign to users. Okay, so let's say that you throw up that OpenID text box like it says. Most OpenID providers don't tell their users their OpenID. So they won't know what to type in there. If your username at a provider is bob123, here's what you're supposed to type into that OpenID box for a few different providers:


Most of those are longer than just typing in a username and password. The OpenID people realize this, so now instead of having one simple login that everyone is used to and can complete in their sleep:


They expect you to show something like this:


Or type your OpenID here:

Yeah, there's nothing more jarring than seeing a bunch of colorful conflicting logos all in one place and typically unrelated to the task at hand. Not to mention that some of those buttons then have to ask what your username is, then will push you to the 3rd party site to actually login and ask what you want to tell your first site. Step back a minute. You're Scott Q. Hummingbird, and you have an Internet-honed attention span. Why the hell do you want to bounce around and answer questions when all you want to do is login?

I know some of these steps are skipped or glossed over when you are already logged in via cookies and have already logged in to the OpenID-asking site before, but still. What's more annoying: another username and password, or this stuff all the time? If you want people to auth into your site, the barrier to entry needs to be damn low. Your users don't know what you're going to offer, really. It takes effort to learn how to login to a site (or to set up a new login), so that means your carrot has to be really big, or the stick it's on needs to be short. OpenID is a long damn stick.

So let's go back to being a web developer. You've decided to use OpenID, and want to integrate it into your site. You'd like to know how it works on the Relying Party side, what sort of things you should store. Basically, how do you know whether a user logged in successfully, and how do you identify them uniquely when they come back from the Identity Provider. Is that information anywhere? Not really. You read the spec and you know how to read a web tech spec, but the OpenID spec is a lot more opaque than you're used to. Screw it, I'll use a library and it figures out all that stuff for me. You look at the list, and there's no documentation; heavy with many requirements, and poor documentation; doesn't work, no documentation; requires libs unnecessary for the concept; looks decent; doesn't work; missing; no documentation; heavy, but with documentation. It's a long list of mostly useless stuff. But there's promise.

And then you get tired and put it aside for another day, when you repeat all the above frustrations.

edit Unexpectedly, Yahoo was very helpful, as well as their link to this recipe. I think I'm going to use lightopenid, because it's light (which I like), and it works.

Category: Technical | Posted by: admin


No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it