This is OAuth. What does it mean for you?
Use your social account to signup!
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.
3 participants in an OAuth transaction:
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:
Step 1 – The user makes a request
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.”
Step 2 – The consumer obtains 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.
Step 3 – The user is redirected to the service provider
Social Platform: “OK, Joe. I’m sending you over to Twitter so you can approve. Take this token with you.”
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).
Step 4 – The user gives permission
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?”
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).
Step 5 – The consumer obtains an access token
Social Platform: “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
Social Platform: “I’d like to post this link to Joe’s stream. Here’s my access token!”
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