Introduction to OAuth (in Plain English)

Last week we 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 Actors

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>

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).

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!”

Recap

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.

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:

• http://hueniverse.com/oauth/
• http://marktrapp.com/blog/2009/09/17/oauth-dummies
• https://dev.twitter.com/docs/auth/oauth/faq
• http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1
• http://googlecodesamples.com/oauth_playground/
• http://www.justin.tv/hackertv/b/259433315

Source:http://blog.varonis.com/introduction-to-oauth/