How it works: Oauth 2.0

Introduction

Oauth 2.0 which stands for 'Open authorization' is an authorization framework that enables an application to obtain limited access to your account on another https service. This is done by delegating the authorization to the application that hosts the user data from the third-party app.

It's basically like giving an app a key that gives them specific permission to access data and perform actions on behalf of a user in another app. This allows the user to provide restricted access to user's account in another service to the client app without providing a username or password. The user can revoke the permission whenever they want.

The steps to grant permission are often referred to as authorization or delegated authorization.

Let's look at an example.

The client app is an app that sends greeting emails on user's behalf. This app requires permission to send emails and access contacts from the user's behalf and they support Oauth 2.0 authorization for the email provider (like Gmail or Outlook) the user uses.
When the email provider is selected user is redirected to the email service. The email provider checks if the user is logged in. If not the user will be prompted to log in.

After login, the user will be shown a screen with permission that will be provided to the client app. This can be accepted or rejected by the user. Once the user grants the permission, they will be redirected to the original app. Now the app can access the user's contact and send emails on their behalf.

This flow is known as authorization code flow. None of this may sound new to the reader as we have seen this flow in our daily internet life frequently.

Let's look into Oauth 2.0's working in detail.

Terminology

First, let's look at the various terminologies present in Oauth 2.0 flow

*Resource Owner *- The user who is providing the access to some portion of their account data to the client app

Client-Application that needs the data or permissions

Authorization Server-This is the server that knows the resource owner. The user will interact with the authorization server when an application is requesting access to their account. The authorization server will prompt the users to grant permission to the client.

Resource Server-The API/server that contains the user's data that is being accessed by the client app. The resource server must be able to accept and validate access tokens and grant access if the user has allowed it.

Redirect URI-The URI to which the authorization server will redirect the resource owner back after granting permission. This also known as callback URI.

Response Type-This is the type of response the client expects. It informs the authorization Server of the desired authorization processing flow. The common response type is 'code'.

Scope-These are the granular permissions that the client app needs. An application can request one or more scopes. The value of scopes is not standardized and is dependent on the service's internal architecture.

Consent-The authorization server takes the scope client has requested and verifies it with the resource owner whether or not they want to give permission. A consent form will be prompted to the user regarding the scopes.

Client Id-This is the value that is used to uniquely identify a client app.

Client Secret-The client secret is essentially the client application's own password to the authorization server. This is a secret only known to the application and authorization server

Authorization Code-This code is a short-lived value that the authorization server sends back to the client. The client will send the authorization code back to the authorization server along with the client secret in exchange for an access token.

Access Token-This is the key the client app use to make API request on behalf of the user. This allows the application to access specific parts of a user's data. OAuth 2.0 doesn't define a specific format for Access Tokens. The JSON Web Token (JWT) format is often used for Access Tokens. For security reasons, the Access Tokens may have expiration dates.

Authorization Code Flow: Under the hood

Now that the terminologies of Oauth 2.0 are clear let's look at the authorization code flow in detail

Before the users come into the picture, the client app will communicate with the authorization server and will establish a working relationship. The authorization server will generate a client id and client secret (sometimes known as app id or app secret), which can be used in future communications.

When the user interacts with the client app and selects service, they will be redirected to the authorization server with a request containing client id, redirect URI, response type and the scopes required.

The authorization server will verify the user and the request. It will prompt the user to log in if the user is not logged in. The scopes requested by the client app will be presented to the user on the consent screen. This will allow the user to grant or deny permissions.

Once the user grants permission to the authorization server, the user will be redirected to redirect URI along with a temporary Authorization code.

The client will then contact the authorization server directly with client id, client secret, and Authorization code. The authorization server will respond with an Access token. This Access token can be used by the client in future interactions for accessing data and performing operations on behalf of user in the resource server.

In this article, we have briefly looked into some concepts related to Oauth 2.0 and its workflow.

I hope this article was helpful.