What exactly is OAuth (Open Authorization)?

What exactly is OAuth (Open Authorization)?

I have gleaned some information from

• OAuth
• Twitter Tutorial: What is OAuth And What It Means To You
• What is OAuth

But I want to learn and know more. I'm looking for info on the lifecycle. Why do most of the social networks rely on this open protocol?

Will it become a de facto in near future with the various technologies (e.g. ASP.NET)?

Solution 1:

What exactly is OAuth (Open Authorization)?

OAuth allows notifying a resource provider (e.g. Facebook) that the resource owner (e.g. you) grants permission to a third-party (e.g. a Facebook Application) access to their information (e.g. the list of your friends).

If you read it stated plainly, I would understand your confusion. So let's go with a concrete example: joining yet another social network!

Say you have an existing Gmail account. You decide to join LinkedIn. Adding all of your many, many friends manually is tiresome and error-prone. You might get fed up halfway or insert typos in their e-mail address for the invitation. So you might be tempted not to create an account after all.

Facing this situation, LinkedIn™ has the good idea to write a program that adds your list of friends automatically because computers are far more efficient and effective at tiresome and error-prone tasks. Since joining the network is now so easy, there is no way you would refuse such an offer, now would you?

Without an API for exchanging this list of contacts, you would have to give LinkedIn the username and password to your Gmail account, thereby giving them too much power.

This is where OAuth comes in. If your GMail supports the OAuth protocol, then LinkedIn can ask you to authorize them to access your Gmail list of contacts.

OAuth allows for:

1. Different access levels: read-only VS read-write. This allows you to grant access to your user list or bi-directional access to automatically synchronize your new LinkedIn friends to your Gmail contacts.
2. Access granularity: you can decide to grant access to only your contact information (username, e-mail, date of birth, etc.) or to your entire list of friends, calendar and whatnot.
3. It allows you to manage access from the resource provider's application. If the third-party application does not provide a mechanism for canceling access, you would be stuck with them having access to your information. With OAuth, there is a provision for revoking access at any time.

Will it become a de facto (standard?) in near future?

Well, although OAuth is a significant step forward, it doesn't solve problems if people don't use it correctly. For instance, if a resource provider gives only a single read-write access level to all your resources at once and doesn't provide a mechanism for managing access, then there is no point to it. In other words, OAuth is a framework to provide authorization functionality and not just authentication.

In practice, it fits the social network model very well. It is especially popular for those social networks that want to allow third-party "plugins". This is an area where access to the resources is inherently necessary and is also inherently unreliable (i.e. you have little or no quality control over those applications).

I haven't seen so many other uses out in the wild. I mean, I don't know of an online financial advisory firm that will access your bank records automatically, although it could technically be used that way.

Solution 2:

What is OAuth?

OAuth is simply a secure authorization protocol that deals with the authorization of third-party applications to access the user data without exposing their password. (e.g. login with Facebook, gPlus, Twitter in many websites) all work under this protocol.

Parties involved

The Protocol becomes easier when you know the involved parties. Basically, there are three parties involved: OAuth Provider, OAuth Client, and Owner.

• OAuth Client (Application Which wants to access your credential)
• OAuth Provider (eg. Facebook, Twitter, etc.)
• Owner (the person with Facebook, Twitter, etc. account )

How It Works

I have supposed a scenario where a website (Stack Overflow) needs to add a login with the Facebook feature. Thus Facebook is OAuth Provider and the Stack Overflow is OAuth Client.

1. This step is done by the app's developer. At the very beginning, Facebook (OAuth Provider) has no idea about the Stack Overflow (OAuth Client) because there is no link between them. So the very first step is to register Stack Overflow with Facebook developers site. This is done manually where developers need to give the app's information to Facebook like the app's name, website, logo, redirectUrl (important one). Then Stack Overflow is successfully registered, has got client Id, client secret, etc from Facebook, and is up and running with OAuth.

2. Now when Stack Overflow's user clicks login with Facebook button. Stack Overflow requests Facebook with ClientId (Facebook uses it to recognize the client) and redirectUrl (Facebook will return back to this URL after success). Thus the user gets redirected to the Facebook login page. This is the best part user(owner) is not giving their Facebook credential to Stack Overflow.

3. After Owner allows Stack Overflow to access the information. Then Facebook redirects back to Stack Overflow, along with authcode using the redirectUrl provided at step 2.
4. Then Stack Overflow contacts Facebook along with the obtained authcode to make sure everything is okay.
5. Only then Facebook will give access token to Stack Overflow. Then access token is used by Stack Overflow to retrieve the owner's information without using a password. This is the whole motive of OAuth, where actual credentials are never exposed to third-party applications.

For More:

Quick video

Web Link

Solution 3:

Simply put OAuth is a way for applications to gain credentials to your information without directly getting your user login information to some website. For example if you write an application on your own website and want it to use data from a user's facebook account, you can use OAuth to get a token via a callback url and then use that token to make calls to the facebook API to get their use data until the token expires. Websites rely on it because it allows programmers to access their data without the user having to directly disclose their information and spread their credentials around online but still provide a level of protection to the data. Will it become the de facto method of authorization? Perhaps, it's been gaining a lot of support recently from Twitter, Facebook, and the likes where other programmers want to build applications around user data.

Solution 4:

OAuth(Open Authorization) is an open standard for access granting/deligation protocol. It used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. It does not deal with authentication.

Or

OAuth 2.0 is a protocol that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials.

• Analogy 1: Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything. src from auth0

• Analogy 2: Assume, we want to fill an application form for a bank account. Here Oauth works as, instead of filling the form by applicant, bank can fill the form using Adhaar or passport.

  Here the following three entities are involved:

  1. Applicant i.e. Owner
  2. Bank Account is OAuth Client, they need information
  3. Adhaar/Passport ID is OAuth Provider

Solution 5:

Oauth is definitely gaining momentum and becoming popular among enterprise APIs as well. In the app and data driven world, Enterprises are exposing APIs more and more to the outer world in line with Google, Facebook, twitter. With this development a 3 way triangle of authentication gets formed

1) API provider- Any enterprise which exposes their assets by API, say Amazon,Target etc 2) Developer - The one who build mobile/other apps over this APIs 3) The end user- The end user of the service provided by the - say registered/guest users of Amazon

Now this develops a situation related to security - (I am listing few of these complexities) 1) You as an end user wants to allow the developer to access APIs on behalf of you. 2) The API provider has to authenticate the developer and the end user 3) The end user should be able to grant and revoke the permissions for the consent they have given 4) The developer can have varying level of trust with the API provider, in which the level of permissions given to her is different

The Oauth is an authorization framework which tries to solve the above mentioned problem in a standard way. With the prominence of APIs and Apps this problem will become more and more relevant and any standard which tries to solve it - be it ouath or any other - will be something to care about as an API provider/developer and even end user!