Using OpenID

The talks at OSCON 2013 were hit and miss--something I've heard is fairly normal for tech conferences in general--but I definitely came away with a favorite. "Reducing Identity Pain" by Tim Bray was a forty-minute session on how to unique identify your users without requiring a username and password.

Why Username/Password Authentication Is Bad

The talk examines some behaviors among users that are forced to make a username/password. First, making username/password's for every site is laborious. If the user comes to your site and sees they need a create a user profile with a username and password, often times they just leave your site. Why? It's hard to create a new username and password for a site that may be a one-off use. Some sites make it even harder by defining very strict password policies guaranteeing that the user will not be able to remember their password. In fact, some users will just fill the password field with random garbage and once they're logged in use cookies. Once the cookies expire they just reset their password with more garbage. This is all very laborious for the user.

Even worse is when users don't use unique passwords. They implicitly trust you with their username/password, which may be used by them elsewhere. Sure, it's their fault for not using unique passwords, but it's also your fault for taking storing in the first place. Getting username/password combos hacked is horrible PR. When you accept them you have to then spend time and resources to make sure they're securely stored. What are you really getting from them that makes them worth the trouble?

A Painless Alternative

So how can we consistently identify a user without going through this identity pain? OpenID is one alternative. While the protocol for OpenID may seem relatively complex, the idea is pretty simple. First, a user gets an account with an OpenID provider. Most users already have at least a Facebook account or an email account from a large provider (Google, Yahoo, Microsoft), so that's usually taken care of. When the user comes to your site, they can choose from a list of providers (actually just a list of urls designated by the OpenID providers) or manually input a url (see step 1 in the diagram below).

I was initially confused where these widgets came from as they're not provided by the OpenID specification. Usually they come from individual libraries that implement OpenID.

Once the user sends their provider url back to your server, which then forwards them to that provider (see step 3 in the OpenID workflow diagram above). This HTTP request can include specific attributes the server wants to know about the user, but in general email is always included reponse. The OpenID provider usually provides a nice list of information being shared. Again, if the person is already logged in to their OpenID provider, this is a one-click step!