DEV Community

Cover image for πŸ”‘ OAuth 2.0 flows explained in GIFs
Hem
Hem

Posted on

πŸ”‘ OAuth 2.0 flows explained in GIFs

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 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).

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

  1. Authorization Code Grant
  2. Authorization Code Grant with PKCE
  3. Client Credentials Grant
  4. Resource Owner Password Credentials Grant
  5. Implicit Grant

1. Authorization Code Grant flow

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

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

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

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?

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) ?

2.2 Authorization Code Grant Flow - PKCE - What is a Code Challenge vs. Code Verifier

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

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

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

Also, this is the simplest of all flows.

4. Resource Owner Password Credentials Grant flow

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

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

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

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 to use the Authorization Code Grant or any other suitable grant types instead of Implicit.


Hope this post was useful. Checkout RFC 6749, RFC 7636 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!✨


Top comments (15)

Collapse
 
olegkarasik profile image
Oleg Karasik

Great job!

Animations are very nice and clearly explain the flows (I will share these with my team).

One small suggestion (if it is appropriate) - it would be great if GIFs would include a "step of steps" information somewhere (maybe at the top) and were a bit slower :)

Collapse
 
yaorenjie profile image
Yao Ren Jie

Great jobs, the authentication things are always confusing to me. Thanks to the clear explanation GIFs.

Collapse
 
hem profile image
Hem

Thanks! Glad to know that it was useful 🀠

Collapse
 
pa1b profile image
Pavan Bellamkonda

Great content and awesome animations. May I know what tool you used to make these animations?

Collapse
 
hem profile image
Hem

Thanks! Started out with Slides for the layout and planning the flow. Made use of Adobe Premier to put them together πŸ˜€

Collapse
 
shostarsson profile image
RΓ©mi Lavedrine

Absolutely great explanation of the flows.
I really love it a lot.

Great job.

Collapse
 
hem profile image
Hem

Thanks a lot πŸ˜ƒ !

Collapse
 
bkoprivica profile image
Bran Koprivica

Cast your mind back to the halcyon days of the 2000s and 2010s when computer science still reigned supreme, its paradigms and methodologies, such as UML, hailed as the pinnacle of notation languages. Alas, stakeholders (also known as "holders of steaks") could never grasp UML's rather simple abstractions. Instead, they started pushing developers to come up with something more palatable, such as... shiny blinking GIFs. The shinier the better - as pronounced by the steak-holders. Shame on the Three Amigos of the 90s who created UML 1.0 instead of relying on the good old GIF technology, eh? Who cares that GIF conveys nothing to developers? What is important is that it shines and blinks so that even the blind eyes of the steak-holders can notice that "something is going on", or "something tangible is being produced". The tides have turned topsy-turvy, and a growing chorus of users now demands more visually dazzling deliverables over substance and functionality: If Thy Don't Shine, Steak-Holders Won't Buy.

Collapse
 
sonnk profile image
Nguyen Kim Son

Awesome animation and a thorough write on PKCE! Could I use the gifs on SimpleLogin docs :) ?

Collapse
 
hem profile image
Hem

Thanks! Feel free to use πŸ˜€

Collapse
 
raithlin profile image
Stephen Metcalfe

Well done on explaining a tough subject in such an easy to follow manner! Sharing this with my team.

Collapse
 
eomm profile image
Manuel Spigolon

This blog post is still useful in 2022 πŸ‘

Collapse
 
hosamaly profile image
Hosam Aly

Very informative. Thanks!
I hope that you'll consider typing out the steps shown in the animations for the benefit of those of us who are unable to see those colours easily.

Collapse
 
devgalaxy profile image
Ahmed Badawy

You are awesome in the scene of the word, really this is a great article.