11436 SSO

OAuth: The valet key metaphor

Gregory Brail
Feb 04, 2012

OAuth has taken off as a standard way for apps and websites to handle authentication. But OAuth is a confusing spec that can be hard to pin down.

I wanted to talk a little about what is OAuth and when you should use it for your API – hopefully pin it down a little in a few blog posts. I covered a lot of this in OAuth: The Big Picture. Check out the video and slides! 

Let’s start with what is OAuth and why it came about.

The developers of OAuth set out to solve the problem that services and passwords don’t mix well as you start to combine apps and mash them up.

Imagine, in today’s environment of web APIs and mobile apps, if every web site that used an API from another web site had to share and store that web site password. Soon you’d have the proliferation of your passwords all over the Internet with every service you’ve used from Facebook, to Twitter, to Skype, to your bank account. Do you trust them all with your password? 

What is OAuth?

It is another way to authenticate to a service - a security protocol that allows users to grant third-party access to their web resources without sharing their passwords.

OAuth supports this “delegated authentication” between web apps using a security token called an "access token." Rather than relying on a single password as the master key for every app that accesses an API, OAuth uses this token.  

An OAuth token gives one app access to one API on behalf of one user.

Eran Hammer-Lahav, a spec author for OAuth, compares the token to a valet key.  This is an apt metaphor.

For most people, their car is one of their most valuable possessions, valued in tens of thousands of dollars.  They are convenient places to leave our other valuables like computers and clothing.  Yet we are sometimes required to give them to a parking attendant or valet whom we’ve not met before. A valet key solves the problem – it’s an access token with limited rights that can operate the vehicle but not grant access to the trunk or glove box.

For great information about the history of OAuth, see Eran Hammer-Lahav’s guide. 

How does it work?

Simply, there are three entities (legs) to consider for an OAuth scenario:

  • The user of a service – let’s call him Bob
  • A client (a Web app, a mobile app) – let’s take bit.ly as an example client
  • The server (where the service runs) – let’s take twitter as an example

How does our user Bob interact with Twitter through his bit.ly account?

    1 - Bob visits bit.ly on the web, which uses a service provided by Twitter. Bob already has logins for bit.ly and Twitter.

    2 - Behind the scenes, bit.ly uses it’s OAuth credentials to begin the authentication process for Bob.

    Bit.ly redirects Bob temporarily to twitter.com to log in. (bit.ly never sees Bob’s Twitter password).

    (The page hosted by twitter that asks if an application can access Twitter on your behalf is probably familiar to most of us by now.)

    Note that twitter shows Bob what rights the app is asking for, and importantly what the app will not be able to do – in this case, see that bit.ly cannot access Bob’s direct messages or see his twitter password. 

    3 - If this sign in is successful, bit.ly uses its own OAuth credentials (token) to retrieve credentials for Bob (that’s the valet key that allows bit.ly to use Twitter on Bob’s behalf).

    4 - Bit.ly stores Bob’s credentials along with Bob’s account. They allow him to use bit.ly and only bit.ly to access Twitter.


    Why is it important?

    What if bit.ly is hacked and someone steals all the passwords. Bob will have lost his bit.ly password but the thieves don’t have his Twitter password.

    The Twitter API team, knowing that bit.ly has been hacked, can decide to revoke bit.ly OAuth credentials. Now everyone that uses bit.ly can’t use twitter. This is extreme but can be important when an app is severely comprised so you don’t have to change your passwords.

    On the other hand, if Bob decides to change his Twitter password, the token that bit.ly has for Bob that allows him to access Twitter is unaffected.

    Bit.ly never had Bob’s twitter password so he doesn’t have to do anything at bit.ly – and he will be able to access twitter through bit.ly next time he tries.

    Next time: The OAuth flow for mobile apps

      Creating World-Class Developer Experiences