DEV Community

Cover image for OAuth 2.0 Explained In Simple Terms (With Visuals)
Jean-Paul Rustom
Jean-Paul Rustom

Posted on

OAuth 2.0 Explained In Simple Terms (With Visuals)

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.

Image description

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

Image description

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

Image description

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.

Image description

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

Image description

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.

Image description

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.

Image description

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.

Image description

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.

Image description

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.

Image description

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.

Image description

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.

Image description

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.

Image description

Image description

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.

Image description

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

Image description

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.

Image description

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

Top comments (0)