A Briefing of OAuth

Back in the day, if a third-party application needed to access certain content from another application, the user would have to provide login details (i.e. username and password) of the application holding the content to the third-party app in order to enable access to the resources. This method would introduce many security risks as the third-party application could now gain full access into our resource provider application using the login credentials we entered. We may not know what the third-party app actually intends to do with our login info or how they store it in their system. All the security measures implemented by the resource provider application may be rendered moot leaving your sensitive information exposed. Therefore, several methods were introduced to address these issues of the former method and OAuth is one of them.

What is OAuth?

We’ve been hearing a lot about ‘OAuth’ lately because it has been gaining popularity in the web application business. So what is OAuth? And how do you even pronounce it?

Simply put, OAuth allows an end-user’s account information (such as Facebook, Twitter) to be used by third-party applications or services without having to share the login details of the identity provider (it’s pronounced “oh-auth” by the way). It is a standard for authenticating and authorizing users on the internet by using tokens for access.

So, where is OAuth used? I’m pretty sure you would have used OAuth to log in to sites atleast once in your life. A simple example of OAuth can be demonstrated using Medium itself. When you click on the Login button on Medium, you will be given a number of options for how you want to log in.

You then click on one of these options (for example, Sign in with Facebook) and you will be redirected to a window of Facebook asking you to confirm access to your account details.

When you continue, Facebook authenticates you and then Medium logs into their website using permission obtained from Facebook. This is a basic login scenario using OAuth.

There are 2 types of OAuth, namely, OAuth 1.0 and OAuth 2.0. OAuth 2.0 is a complete rewrite of its predecessor but it is not backwards compatible with OAuth. Therefore, OAuth 2.0 should be considered as a completely new protocol.

How OAuth works?

Keep in mind that there are four different entities involved in the OAuth process. These entities are,

1. Resource owner — The identity owner who is capable of granting access to a protected resource. Generally called the end-user.
2. Resource server — The server hosting the protected resources. Also known as the API server.
3. Client — The application requesting access to the protected resources on behalf of the resource owner.
4. Authorization server — The server issuing access tokens to the client after authenticating the client and resource owner.

Let’s take a look at how OAuth 1.0 works first.

The key to understanding how this works is by studying the authorization flow, which is the process that clients go through to connect to a particular site. In OAuth 1.0, the flow can be broken down into three primary steps as follows,

Step 1 — Temporary Credentials Acquisition

The first step is the process of obtaining temporary credentials, a.k.a the Request Token, which has a short lifespan and is only used for initial authorization. It cannot grant access to any resources on the server. To obtain the request token, the client sends an HTTP request to the authorization server containing certain details such as client key, authorization callback URL, request signature, etc. As this is just an overview of OAuth, I will not go deeper into the concepts used. The server then validates the key and signature and returns temporary credentials containing OAuth token and a token secret which will be used in the later steps.

Step 2 — Authorization

The client sends the token received earlier to the authorization callback URL which in turn will request authorization from the user. When the client gets authorized, the OAuth token gets marked as authorized and gets returned back to the client along with another token called the OAuth verifier.

Step 3 — Token Exchange

The final step is to exchange the temporary credentials for long term credentials (i.e. exchanging the request token for an Access token). To do this, a request signed by the temporary credentials, including the OAuth verifier token, is sent to the authorization server. Once the request is validated, an access token will be sent back to the client. The client can now use the access token to access the authorized data and services from the resource provider.

Moving on to OAuth 2.0.

OAuth 2.0 consists of several Grant methods which feature different authorization flows depending on the application. To explain OAuth 2.0, I will use the most commonly used Grant which is called the Authorization Code Grant. This authorization flow can be divided into two steps.

Step 1 — Obtaining Authorization Code

The first step in this flow involves obtaining an Authorization Code from the authorization server. The client sends a request containing a client ID, callback URL, scope of intended actions, state, etc. Once the parameters are validated by the authorization server, the user will be asked to login and approve the client. If the client is approved, the user will be redirected back to the client along with an authorization code and the original state.

Step 2 — Acquiring Access Token

Instead of obtaining and resending a temporary token like in OAuth 1.0, the authorization code is obtained and resent back to the authorization server in OAuth 2.0. A request containing the authorization code along with the grant type, client ID, client secret key, and a callback-URL is sent as backchannel call. The server will then respond to the client with a JSON object containing the access token and a few parameters like token expiration time, token type, and refresh token.

OAuth 1.0 vs OAuth 2.0

Generally, OAuth 1.0 is considered to be more secure as it takes extra steps with multiple tokens in the authorization flow. But OAuth 1.0 was mainly browser based, which means that client applications (both desktop and mobile) that were not browser based had to open a browser to the required service, complete the authentication and copy the access token back to the application. This method is very inefficient and irritating as well. With OAuth 2.0, new and better ways were implemented to support authorization directly from within the client applications.

In OAuth 2.0, the access tokens issues have a short life span, whereas the access tokens issued in OAuth 1.0 could be stored for a very long time [1]. This is an added security feature in OAuth 2.0 as the same Access token could not be used for very long periods; access in maintained by having the refresh token re-authorize the application and obtain a new access token.

OAuth 2.0 signatures are much less complicated than that of OAuth 1.0 which means that no special parsing, sorting or encoding techniques will be required. It also features cryptographic methods which eliminates the need of implementing such methods in the client applications.

To top is all off, OAuth 2.0 introduces several new authorization flows to support more secure authorization based on the client application being developed.

An OAuth 2.0 example.