Introduction to OAuth (in Plain English)

Introduction to OAuth (in Plain English)

We’ve talked about giving away your passwords and how you should never do it.  When a website wants to use the services of another—such as Bitly posting to your Twitter stream—instead of asking you to share your password, they should use OAuth instead.

OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

This is a quick guide to illustrate, as simply as possible, how OAuth works.

The OAuth Flow

There are 3 main players in an OAuth transaction: the user, the consumer, and the service provider.  This triumvirate has been affectionately deemed the OAuth Love Triangle.

In our example, Joe is the user, Bitly is the consumer, and Twitter is the service provided who controls Joe’s secure resource (his Twitter stream).  Joe would like Bitly to be able to post shortened links to his stream.  Here’s how it works:

Step 1 – The User Shows Intent

Joe (User): “Hey, Bitly, I would like you to be able to post links directly to my Twitter stream.”
Bitly (Consumer): “Great! Let me go ask for permission.”

Step 2 – The Consumer Gets Permission

Bitly: “I have a user that would like me to post to his stream. Can I have a request token?”
Twitter (Service Provider): “Sure.  Here’s a token and a secret.”

The secret is used to prevent request forgery.  The consumer uses the secret to sign each request so that the service provider can verify it is actually coming from the consumer application.

Step 3 – The User Is Redirected to the Service Provider

Bitly: “OK, Joe.  I’m sending you over to Twitter so you can approve.  Take this token with you.”
Joe: “OK!”

<Bitly directs Joe to Twitter for authorization>

This is the scary part. If Bitly were super-shady Evil Co. it could pop up a window that looked like Twitter but was really phishing for your username and password.  Always be sure to verify that the URL you’re directed to is actually the service provider (Twitter, in this case).

Step 4 – The User Gives Permission

Joe: “Twitter, I’d like to authorize this request token that Bitly gave me.”
Twitter: “OK, just to be sure, you want to authorize Bitly to do X, Y, and Z with your Twitter account?”
Joe: “Yes!”
Twitter: “OK, you can go back to Bitly and tell them they have permission to use their request token.”

Twitter marks the request token as “good-to-go,” so when the consumer requests access, it will be accepted (so long as it’s signed using their shared secret).

Step 5 – The Consumer Obtains an Access Token

Bitly: “Twitter, can I exchange this request token for an access token?”
Twitter: “Sure.  Here’s your access token and secret.”

Step 6 – The Consumer Accesses the Protected Resource

Bitly: “I’d like to post this link to Joe’s stream.  Here’s my access token!”
Twitter: “Done!”


In our scenario, Joe never had to share his Twitter credentials with Bitly.  He simply delegated access using OAuth in a secure manner.  At any time, Joe can login to Twitter and review the access he has granted and revoke tokens for specific applications without affecting others.  OAuth also allows for granular permission levels.  You can give Bitly the right to post to your Twitter account, but restrict LinkedIn to read-only access.

OAuth Isn’t Perfect…Yet

OAuth is a solid solution for browser based applications and is a huge improvement over HTTP basic authentication.  However, there are limitations, specifically with OAuth 1.0, that make it far less secure and less user-friendly in native and mobile applications.

OAuth 2.0 is a newer, more secure version of the protocol which introduces different “flows” for web, mobile, and desktop applications.  It also has the notion of token expiration (similar to cookie expiration), requires SSL, and reduces the complexity for developers by no longer requiring signing.

Other Resources

Hopefully this was a good primer to get you familiar with OAuth so the next time you see “Sign-in with Twitter” or similar delegated identity verification, you’ll have a good idea of what is going on.

If you want to dive deeper in into the mechanics of OAuth, here are some helpful links:

Get the latest security news in your inbox.

Next Article

Giving Away Your Passwords

  • Ross Patterson

    “Note: This is the scary part. If Bitly were super-shady Evil Co. it could pop up a window that looked like Twitter but was really phishing for your username and password. Always be sure to verify that the URL you’re directed to is actually the service provider (Twitter, in this case).”

    And that’s the major problem in OAuth and every similar third-party-authentication system (e.g., OpenID). We all know, and for some reason, we’re willing to ignore, websites can be forged.

  • Rob Sobers

    @Ross – thanks for the comment! You’re right, and that’s why I was sure to point that out.

    Even though things have become more automatic for the end user (especially if you’re already logged in), we still have use our Internet Street Smarts.

    Scott Hanselman wrote a great post yesterday about keeping your guard up online:

  • Stephen Gadsby

    Thank you for writing this. You’ve done a wonderful job of making OAuth understandable.

    I do believe you missed completing the last sentence of the second two last section of this article though: “…and reduces the complexity for developers by no longer requiring.”

  • Rob Sobers

    @Stephen Thanks for the catch! I’ve updated the post.

  • Pingback: HTML5 Facts and Myths, JavaScript Boulder Dash, Daftunes, and more… « Ekancil Consultant & Computing Sdn Bhd()

  • Sion Williams

    Thanks for this. Perfectly explained, and at a level my little brain could cope with.

    • LeBron James Instagram

      I agree with you.

  • loadaverage

    Very nice 🙂

  • Sivakumaran

    Very well explained!!

  • Domènec Sos Vallès

    Excellent. Wish I had a similar introduction when I had to figure out SAML and WS-Federation on my own and deep diving in protocol documentation 🙂

  • Nawaz Khurshid

    Perfect blog for newbie!

  • عيسى محمد علي

    The best article I have read about oauth!
    Thank you!

  • Mike Stoddart

    Fantastic explanation, thanks!

  • Saket Rajput

    Nicely explained

  • NTRao

    Excellent, very well explained. Thank you

  • frankfu

    Thanks for sharing this. The examples really helped a great deal.

  • Mārtiņš Briedis

    Thanks, this helped alot. OAuth is scary until you lay it out like this!

  • fractalspace

    “triumvirate” is plain English now

  • Christian Pietersen

    Hey Rob, I’ve done a swimlane diagram of this that I can share with you if you like

  • sarnobat