OAuth has become a big technology in recent years, our App Experts are here to give you all the information you need to get started.

What is OAuth?

It’s a secure way to authenticate access to and share resources with third parties.

Example

Say we have a profile on a website x.com and we want to upload pictures from Facebook onto our x.com profile. Without OAuth, the flow would look something like this:

  1. From x.com we click on the ‘Upload pictures from Facebook’ button.
  2. While still on x.com, we’d have to input our Facebook Username and Password.
  3. We’re now able to select which images we want to upload.

In this scenario, we’ve passed our Facebook credentials over to an unverified third party (x.com) for handling. There’s no telling what this third party is doing with these credentials; they could be stored, distributed, or used; without our knowledge.

Now consider the same flow with OAuth:

  1. From x.com we click on the ‘Upload pictures from Facebook’ button.
  2. We get a popup from a verified facebook.com source asking for our Username and Password.
  3. We get another popup from a verified facebook.com source asking us to allow/disallow x.com to use our pictures.
  4. If we allow the service, we can now select the images we want to upload.

Now, in this improved scenario, we’re achieving the same goal, the sharing of images between Facebook and a third party, but without passing any, Facebook-based, secure or sensitive information to x.com (Facebook Password and Username). Our credentials are securely handled by the appropriate services throughout.

OAuth roles

With OAuth we follow the concept of decentralization of control; we have defined a set of roles, each of which will be fulfilled by different, specialized, servers. This improves security while still keeping an eye on efficiency.

The roles are:

Client –The entity requesting access to the resource housed on the resource server. (X.com)

Authorization server – A server, normally owned/operated by the same entity as the resource server, that will process and potentially authorize access to the resource server.

Resource owner – The entity that owns the requested data. (Our Facebook Profile)

Resource server – The server hosting the requested data. (Facebook’s hosting servers)

The way it works

There are 4 flows/grant types in OAuth 2:

Now for the flows

Authorization Code Grant
  1. Client sends a request to Resource Owner providing Client Id (x), Redirect Url (http://www.x.com), and scope (Photos).
  2. Resource Owner responds with an Authorization Code.
  3. Client then passes Authorization Code to the Authorization Server and receives Access Token.
  4. Client can now access the protected resource on the Resource Server with the Access Token.
Implicit Grant
  1. Client sends an authorization request to Resource Owner and gets the Access Token.
  2. Client can then use Access Token to access protected resources on the Resource Server.

This is basically the same as Authorization Code Grant, but the Resource Owner and Authorization Server roles are combined to one entity.

You may be, like I was, asking what’s the point of the Authorization Code Grant method if Implicit Grant is easier and uses the same principle. Basically, most people use Implicit Grant, but the Authorization Code Grant method provides an extra level of security and decentralization. Also, if we’re dealing with a large resource provider that has a lot of Authentication Servers, the Resource Owner server can send different Authentication Server urls depending on the load of particular authentication servers.

Resource Owner Password Credentials Grant
  1. Resource Owner provides his own credentials to the Client in order for the Client to access the protected resource.
  2. Client provides credentials to Authorization Server and gets an Access Token in response.
  3. Client can then use that Access Token to access protected resources on the Resource Server.
Client Credentials Grant
  1. Client provides credentials to Authorization Server and gets an Access Token in response.
  2. Client can then use that Access Token to access protected resources on the Resource Server.

Basically that was OAuth 2.0 simplified. Hope you enjoyed the read.

Leave a Reply