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
- Authorization Code Grant
- Authorization Code Grant with PKCE
- Client Credentials Grant
- Resource Owner Password Credentials Grant
- 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.
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)
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) ?
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
.
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.
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.
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.
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)
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 :)
Great jobs, the authentication things are always confusing to me. Thanks to the clear explanation GIFs.
Thanks! Glad to know that it was useful π€
Great content and awesome animations. May I know what tool you used to make these animations?
Thanks! Started out with Slides for the layout and planning the flow. Made use of Adobe Premier to put them together π
Absolutely great explanation of the flows.
I really love it a lot.
Great job.
Thanks a lot π !
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.
Awesome animation and a thorough write on PKCE! Could I use the gifs on SimpleLogin docs :) ?
Thanks! Feel free to use π
Well done on explaining a tough subject in such an easy to follow manner! Sharing this with my team.
This blog post is still useful in 2022 π
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.
You are awesome in the scene of the word, really this is a great article.