OAuth (Open Authorization) is an open standard for token-based authentication and authorization on the Internet. OAuth, which is pronounced "oh-auth," allows an end user's account information to be used by third-party services, such as Facebook, Twitter, LinkedIn, etc. without exposing the user's password.
When a website wants to use the services of another—such as an online service wanting to post to your Twitter, Facebook, LinkedIn, etc. stream—instead of asking you to share your password, they will use OAuth instead.
The user, the consumer, and the service provider. Imagine, Joe is the user, Social Platform is the consumer, and Twitter is the service provider who controls Joe’s secure resource (his Twitter stream). Joe would like Social Platform to be able to post shortened links to his stream. Here’s how it works:
Joe (User): “Hey, Social Platform, I would like you to be able to post links directly to my Twitter stream.”
Social Platform (Consumer): “Great! Let me go ask for permission.”
Social Platform: “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.
Social Platform: “OK, Joe. I’m sending you over to Twitter so you can approve. Take this token with you.”
Joe: “OK!”
Note: This is the scary part. If Social Platform 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).
Joe: “Twitter, I’d like to authorize this request token that Social Platform gave me.”
Twitter: “OK, just to be sure, you want to authorize Social Platform to do X, Y, and Z with your Twitter account?”
Joe: “Yes!”
Twitter: “OK, you can go back to Social Platform 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).
Social Platform: “Twitter, can I exchange this request token for an access token?”
Twitter: “Sure. Here’s your access token and secret.”
Social Platform: “I’d like to post this link to Joe’s stream. Here’s my access token!”
Twitter: “Done!”
In this scenario, Joe never had to share his Twitter secret credentials with Social Platform. 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.
Hopefully this was a good lesson to get you familiar with OAuth so the next time you see “Sign-in with your social account” or similar delegated identity verification, you’ll have a good idea of what is going on.
Origional article by: Rob Sobers
Dennis Roeder
Contributor