OAuth Protocol

Let's study the OAuth protocol and learn how it works.

We'll cover the following

In the World Wide Web, the client can be a web browser, and the server can be an application server.

However, there are more complex scenarios that involve more parties. One such scenario is when a server needs a client’s authorization to retrieve the client’s data from a different server. For example, this could happen when an e-mail application wants to retrieve the email accounts of your friends in a separate social media application in order to add them to your contacts list. OAuth is a protocol that allows this to happen in a secure way.

Note: There are multiple versions of this protocol with significant changes, but we will discuss the OAuth 2.0 version in this lesson.

Entities in OAuth protocol

There are four main entities in OAuth protocol.

Resource owner

The resource owner is the person who gives access to some portion of their data.

Client

The client is the application that attempts to get access to some of the user’s data, e.g., the e-mail application in the above example.

Resource server

The resource server is the application that contains the user’s data to be accessed, e.g., the social media application in the above example.

Authorization server

The authorization server is the server that presents the interface where the user approves or denies the request to their data. In simpler cases, it can be the same as the resource server, but in more complex scenarios, it can be different.

Workflow of the OAuth protocol

The following illustration contains a visualization of the main flow in the OAuth protocol:

  • Initially, the user visits the website of the client application. The client applications redirect the user to a specific webpage of the authorization server dedicated to OAuth. The request to the authorization server contains some additional data, such as a redirect URI back to the client application, the category of user data that is requested, the ID of the client application, etc.

  • The authorization server returns a web page to the user that presents a detailed message about the requested data and the client application that is making the request. The user is given the option to authorize or reject this request.

Note: If the user isn’t logged in to the authorization server, a login prompt will be shown first.

  • When the user approves the request, the authorization server will redirect the user back to the client’s application. Specifically, the user will be redirected back to the redirect URI contained in the original request, but this URI will be enriched with some additional data. One crucial piece of data is an authorization code vended by the authorization server that will represent the permission the user gave to the application code to access their data.

  • The client application will then make a request to the authorization server providing this authorization code in exchange for an access token. Apart from the authorization code, the client application will also provide their client identifier along with a client secret.

  • The client application can then use this access token to make a request to the resource server requesting the user’s data.

When encountering this workflow for the first time, one might question why there is a need for both the authorization code and the access token. The main reason behind this is that the web browser is considered much more insecure when compared to the client application on the backend. So, only the authentication code is exposed to the web browser that cannot retrieve the user’s data without the client’s secret that is securely stored by the client application.

Get hands-on with 1400+ tech skills courses.