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!

By clicking accept, the OpenID provider redirects the user back to your site using the "return_to" field you provided the OpenID library see step 5 in the OpenID workflow diagram above). At this point you have identified the user by their email. What does this mean exactly? Well, anyone can setup their OpenID provider so this doesn't provider any email verification. So the person claiming to be "president_barack_obama@whitehouse.gov" from OpenID provider X doesn't mean he/she actually owns that email, but you can uniquely identify them as that person claiming that email from that OpenID provider.

Show Me the Code

Sounds great, right? What does this actually involve on a developer's part? While the protocol is relatively complex most web frameworks have one or possibly several OpenID libraries you can use. Many are third party, but some are actually built into the framework ready to use (framework developers, take note--this is awesome). Take [Tornado], an asynchronous web framework written in python.

Conclusion

Should you always use OpenID? I would say in most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary. You'd still have to do things like email verification to verify people's emails belong to them if that's important to you. There are, of course, some cases where a username/password are required and it's fine to use them instead. Just remember that if go that route you're causing your users pain. Make sure it's worth it.