1- Introduction

In the early stages of human civilization, users would provide their username and password into a web application, and they would get access to anything they wanted.

Today, in our web apps, we have ways to let our users access information in other applications, without sharing credentials.

OAuth 2.0 is like finding a secret door in the back of your favorite website, guarded by a bouncer.

Instead of just handing over your username and password like it's no big deal, OAuth 2.0 insists on a exchanging tokens, redirect URLs, and authorization codes.

In this article we’ll break down OAuth 2.0 into digestible explanations.

2- Concepts

Okay so let’s explain core concepts for this OAuth thing, and for that we’ll refer to the spec’s example.

Let’s say we have JayP, a printing service called Print Express, and Google Drive, which stores JayP’s photos.

JayP wants to print all photos contained in his Google Drive account, using Print Express.

Instead of uploading all photos from Google Drive to Print Express, we can have Print Express access the photos from Google Drive, using OAuth, without using Google Drive’s credentials.

Now let’s explain few terminology.

1- Resource owner

JayP is referred to as the resource owner.

It is an entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

2- Resource server

Google Drive here is the resource server.

The resource server hosts the protected resources, and can accept and respond to protected resource requests using access tokens.

The spec also mentions something called an authorization server.

The authorization server issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The resource server and the authorization server can be the same.

For the sake of this article, we’ll have the authorization server and the resource server be the same, and not separate entities.

3- Client

Print Express is the client.

A client is an application making protected resources requests on behalf of the resource owner and with its authorization.

3- Flows

In this article, we will cover two out of four flows described in the spec.

1- Authorization Code flow

The authorization code flow is arguably the most generic flow which is primarily used in applications where a client secret can be securely stored on a server.

1- The client FE redirects the user to an authorization endpoint from the resource server, where the user can authenticate and provide consent for the client to access their resources.

2- Upon successful authentication and consent, the authorization server responds with a short-lived authorization code.

3- The client, typically the server-side part, exchanges the authorization code for an access token by making a request to a token endpoint provided by the authorization server. This request includes the authorization code, client ID, and client secret.

4- The authorization server validates the authorization code and client credentials.

If successful it responds with an access token, and optionally a refresh token.

The refresh token can be used to request new access tokens from the token endpoint, in case the last access token is expired, without requiring the end user to sign in again.

5- With the obtained access token, the server-side component of the client can make authorized requests to access protected resources from the resource server by providing the access token in the request headers.

In this flow, the front end part of the client, such as a web browser or a mobile app’s UI, may not see the access token, or if there’s a need for the front end to store it, it may receive it as encrypted from the server-side component.

2- Implicit Flow

The implicit flow is aimed for client applications that do not have a server side part, for example a single page javascript application, or a mobile app.

1- The client FE redirects the user to an authorization endpoint from the resource server, where the user can authenticate and provide consent for the client to access their resources.

2- Upon successful authentication and consent, the resource server directly sends back the access token to the client, in the URL, and without the intermediate step of exchanging an authorization code for a token

3- With the access token in hand, the client can now request access to protected resources from the resource server.

In this case the access token will have a shorter lifespan than the one issued in the authorization code flow, and refresh token is not returned.

Since the access token is returned directly, as is, to the front end, this flow is considered less secure.

4- Tokens

Now before ending this article, let’s add few thing regarding the tokens.

Commonly, both access tokens and refresh tokens can be JWTs, which means in this case they will be self contained. You can check our separate article explaining JWTs.

Tokens represent specific scopes (photos, email address, name) and durations of access, granted by the resource owner, and enforced by the resource server.

The access token provides an abstraction layer, replacing the username and password with a single token understood by the resource server. For this reason, issuing access tokens is more restrictive than the authorization grant used to obtain them.

That's it folks ! Here are other interesting topics: