🔑 OAuth 2.0 flows explained in GIFs
Tags: oauth, security, computerscience, design
Published: 2020-07-14 05:46:03

In this post, we will be covering all OAuth 2.0 flows using GIFs that are simple and easier to understand. This post can be used as a cheat-sheet for future reference as well! 

> **Note**: Feel free to [⏩ skip](#toc) to the flows directly if you are already aware of OAuth.

---

## Hold on, what's OAuth❓

OAuth (Open Authorization) enables third-party websites or apps to access user's data without requiring them to share their credentials. It is a set of rules that makes access delegation possible. The user gets to _authorize_ which resources an app can access and limits access accordingly.

## Terminologies 🧱

Now that we know what OAuth is about, let us quickly cover the terminologies before we dive-in. 

| Term                   | Description                                                  |
| :--------------------- | ------------------------------------------------------------ |
| Client 📦               | The application that seeks access to resources. Usually the third-party. |
| Resource Owner 👤       | The user who owns the resources. It can also be a machine 🤖 (E.g. Enterprise scenarios). |
| Resource 🖼             | Could be images, data exposed via APIs, and so on.           |
| Resource Server 📚      | Server that hosts protected resources. Usually, an API server that serves resources if a proper token is furnished. |
| Authorization Server 🛡 | Server responsible for authorizing the client and issuing access tokens. |
| User-Agent 🌐           | The browser or mobile application through which the resource owner communicates with our authorization server. |
| Access Token 🔑         | A token which is issued as a result of successful authorization. An access token can be obtained for a set of permissions (scopes) and has a pre-determined lifetime after which it expires. |
| Refresh Token 🔄        | A special type of token that can be used to replenish the access token. |

Now, let us relate these terminologies in an abstract OAuth flow based on an example [(1)](https://tools.ietf.org/html/rfc6749#section-1).

> An end-user (resource owner 👤) grants a printing service (app 📦) access to their photo (resource 🖼) hosted in a photo-sharing service (resource server 📚), without sharing their username and password. Instead, they authenticate directly with a server trusted by the photo-sharing service (authorization server 🛡), which issues the printing service delegation-specific credentials (access token 🔑).

Note that our app (client) has to be _registered_ in the authorization server in the first place. A Client ID is returned as a result. A client secret is also optionally generated depending on the scenario. This secret is known only to the authorization server and the application.

Okay, enough theory! It is time for some GIFs to understand the authorization scenarios/flows!

---

## Flows in OAuth 2.0 <a name="toc"></a>

  1. [Authorization Code Grant](#authorization-code-flow)
  2. [Authorization Code Grant with PKCE](#authorization-code-flow-with-PKCE)
      - [Code Transformation Method (CM) - Meet SHA256](#pkce-sha256)
      - [Code verifier (CV) & Code Challenge (CC)](#code-verifier-and-code-challenge)
  3. [Client Credentials Grant](#client-credentials)
  4. [Resource Owner Password Credentials Grant](#resource-owner-password-credentials)
  5. [Implicit Grant](#implicit-grant)

---

### 1. Authorization Code Grant flow  <a name="authorization-code-flow"></a>
It is a popular browser-based authorization flow for Web and mobile apps. You can directly relate it with the above-mentioned example. In the diagram below, the flow starts from the Client redirecting the user to the authorization endpoint.

![1 Authorization Code Grant Flow - confidential clients](https://dev-to-uploads.s3.amazonaws.com/i/2j7kqc7qabtfpl250jf2.gif)

This flow is optimized for _confidential clients_. Confidential clients are apps that can guarantee the secrecy of `client_secret`. A part of this flow happens in the front-channel (until the authorization code is obtained). As you can see, the `access_token` 🔑 exchange step happens confidentially via back-channel (server-to-server communication). 

Now you might naturally wonder, 'What about public clients?!'

### 2. Authorization Code Grant with PKCE  <a name="authorization-code-flow-with-PKCE"></a>

Public clients using authorization code grant flow have security concerns. Be it single-page JS apps or native mobile apps, it is impossible to hide the `client_secret` as the entire source is accessible (via DevTools or App Decompilation). Also, in native apps where there is a custom URI scheme, there is a possibility of malicious apps intercepting the authorization code via similar redirect URIs.

To tackle this, the Authorization Code Grant flow makes use of Proof Key for Code Exchange (PKCE). This enables the generation of a secret at runtime which can be safely verified by the Authorization Server. So how does this work?

#### 2.1. Transformations - Meet SHA256  <a name="pkce-sha256"></a>

Basically the client generates a random string named `Code Verifier` (CV). A `Code transformation method` (CM) is applied to the CV to derive a `Code Challenge` (CC) ✨ As of now, there are two transformation methods `plain` or `S256` (SHA-256)

![2.1 Authorization Code Grant Flow - PKCE - How does SHA256 work?](https://dev-to-uploads.s3.amazonaws.com/i/tw9nu7l1yufx3bczy7fi.gif)

In plain transformation, CC will be equal to CV. This is not recommended for obvious security reasons & hence S256 is recommended. SHA256 is a hash function. On a high-level, it takes input data and outputs a string. However, there are special characteristics to this output string:

- This string is unique to the input data and any change in the input will result in a different output string! One can say, it is a signature of the input data.
- The input data _cannot_ be recovered from the string and it is a one-way function (Refer the GIF above).
- The output string is of fixed-length.

#### 2.2. How do we generate the Code Challenge (CC) from the Code verifier (CV) ?  <a name="code-verifier-and-code-challenge"></a>

![2.2 Authorization Code Grant Flow - PKCE - What is a Code Challenge vs. Code Verifier](https://dev-to-uploads.s3.amazonaws.com/i/tfuwug010zprz84p702o.gif)

You might have already guessed it. Take a look at the diagram to understand how CC is generated from CV. In this case, since SHA256 is used, CV cannot be generated from CC (Remember, it is a one-way transformation). Only CC can be generated from CV (Given that the transformation method is known - `S256` in our case).


#### PKCE flow
Note that the flow starts with CV and CC generated first replacing the `client_secret`.

![Authorization Code Grant with PKCE ](https://dev-to-uploads.s3.amazonaws.com/i/odkf14kzlb5gcbvrmuvx.gif)

Now that we know how CV, CC is generated, let us take a look at the complete flow. Most parts are similar to the authorization code grant flow. The CV and CC are generated even before the flow starts. Initially, only the CC and CM are passed to obtain an authorization code. Once the authorization code is obtained, the CV is sent along to obtain the access token. 

In order for the authorization server to confirm the legitimacy, it applies the transformation method (CM, which is SHA256) on the received CV and compares it with the _previously-obtained_ CC. If it matches, a token is provided! Note that even if someone intercepts the authorization code, they will not have the CV. Thanks to the nature of the one-way function, a CV cannot be recovered from CC. Also, CV cannot be found from the source or via decompilation as it is only generated during runtime!

### 3. Client Credentials Grant flow <a name="#client-credentials"/>

In the above flows, a resource owner (user) had to provide consent. There can also be scenarios where a user's authorization is not required every time. Think of machine-to-machine communication (or app-to-app). In this case, the client is confidential by nature and the apps may need to act on behalf of themselves rather than that of the user.

![4 Client Credentials Grant](https://dev-to-uploads.s3.amazonaws.com/i/gp4n79x84xujj8mn625w.gif)

Also, this is the simplest of all flows.

### 4. Resource Owner Password Credentials Grant flow <a name="#resource-owner-password-credentials"/>

This flow is to be used only when there is a _high degree of trust_ between the resource owner and the client. As you can see, initially, the username & password is obtained from the R.O and are used to fetch the `access_token`. The username & password details will be discarded once the token is obtained. 

![3 Resource Owner Password Credentials grant](https://dev-to-uploads.s3.amazonaws.com/i/6hsfukc7f4rnopbsy04f.gif)

This flow is _not recommended_ for modern applications and is often only used for legacy or migration purposes. It carries high risk compared to other flows as it follows the password anti-pattern that OAuth wants to avoid in the first place!

### 5. Implicit Grant flow <a name="#implicit-grant"/>

This flow is _no longer recommended_ officially! Implicit grant was considered an alternative to Authorization Code Grant for public clients. As you can notice, the public client does not contain the `client_secret` and there is no back-channel involved. In fact, the access token is obtained immediately after the consent is obtained.

![5 Implicit Grant](https://dev-to-uploads.s3.amazonaws.com/i/90t3te63144tcdven41w.gif)

However, the token is passed in the URL fragment (Begins with `#`) which will never be sent over the network to the redirect URL. Instead, the fragment part is accessed by a script that is loaded in the frontend (as a result of redirection). The `access_token` will be extracted in this manner and subsequent calls are made to fetch the resources. As you can already see, this flow is susceptible to access token leakage and replay attacks. 

It is [recommended](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2) to use the Authorization Code Grant or any other suitable grant types instead of Implicit.

---

Hope this post was useful. Checkout [RFC 6749](https://tools.ietf.org/html/rfc6749), [RFC 7636](https://tools.ietf.org/html/rfc6749) to dig deeper into the steps involved in each of the flows.

Feel free to share your thoughts as well. Don't forget to share this post if you found it useful 🚀

Let me know what you would like to see next as a part of the GIF series! Until then, stay OAuthsome!✨

| [🐥 Twitter](https://twitter.com/HemSays) | [💼 LinkedIn](https://www.linkedin.com/in/hems23/) |
|---|---|

---