Passwords are hard.

For a user, they're hard to remember, hard to keep safe, and occasionally even hard to come up with. To ease the mental burden of remembering passwords, people often resort to reusing the same password across multiple services. Advanced users will often take advantage of password management applications to easily keep track of multiple complex passwords, but they're few and far between. Many people still keep their passwords on a slip of paper at their desk.

For developers, simply storing passwords in a safe manner is a challenge – one that we've discussed in the past. Giving our users safe and secure ways of recovering lost or forgotten passwords is another challenge.

For businesses, stolen passwords are a PR nightmare. As I wrote this post, LinkedIn was doing damage control after hackers stole over six million passwords and leaked them online. EHarmony has just announced that its password database has also been stolen and leaked. Even if your password database was properly hashed and salted, having it leaked to the public is still an embarrassment for your business.

So why bother with passwords? Why not make them somebody else's problem?

OAuth is a technology that lets you do just that.

OAuth example
You've probably used OAuth already

OAuth is an open authenticate standard that allows you to authenticate your users against a third party authentication service provider. You will never have to directly see your users’ passwords. There’s a good chance that you’ve already been exposed to this technology as a user (see figure to the right).

If our user (let’s call him John) were to log into your service the old fashioned way, the protocol would be a conversation something like this:

John: Hi there! I’d like to log into your website!

You: Sure, what’s your username and password?

John: I’m John007 and my password is correcthorsebatterystaple.

You then go off to validate a hash of the password against your database.

You: Looks good, come on in John!

The conversation with the OAuth protocol is a little bit different. This is how Mary would sign onto your service using Facebook as an authentication provider:

Mary: Hi there! I’d like to log into your website!

You: Hey Facebook, could you verify Mary for me? And while you’re at it, could you ask her if I could see her Facebook display picture? It would be cool if I could use that on my site too.

Facebook and Mary then go to a place where you can’t hear them.

Facebook: Hi Mary, could you tell me your Facebook username and password?

Mary: Sure Facebook! I’m Mary01 and my password is Tr0ub4dor&3

Facebook: Thanks Mary, that checks out! Also, do you trust this site with your display picture?

Mary: Sure Facebook, I can trust them with that, but nothing else.

Facebook will then let you know that Mary is who she says she is, and pass you tokens that you can use to retrieve her Facebook display picture.

While the OAuth conversation is a lot more complicated, it has two advantages:

  • You never have to deal with the responsibility of storing passwords, or even touching their password. You can rely on your authentication provider, which hopefully has much more mature and secure authentication techniques in place. (Google and Facebook in particular offer impressive two factor authentication.)
  • You can also ask permission to use other resources from the service provider. In Mary’s case, we asked to use her Facebook display picture.

The uses of OAuth go beyond just authenticating users and getting rid of passwords liability. Many APIs these days require OAuth authentication to work. Let’s say that you want to create a mobile application that reads your user’s Twitter feed. Twitter is not going to let you log directly into your user’s account with his or her username and password. Twitter just doesn’t trust you that much and neither should your user have to trust you that much. Twitter’s API requires that you use OAuth authentication to validate your user and ask your user’s permission to read his Twitter feed.

As a developer creating a web facing API, it might be a good idea to even set your application up as an OAuth authentication provider. Third party applications that wish to access your services will never have to be trusted with your users’ passwords.

OAuth has quickly become an important part of how authentication and public API’s on the web works. It’s important for developers to be aware of it and have an understanding of it. Best of all, it’s a very easy technology to pick up and learn. If you’re a developer, I’d recommend spending a few hours playing with Twitter’s or Facebook’s API – it’s a great way to pick up on the details of OAuth.


Topics: Security

Leave a Reply