Now, let’s take a more detailed look at the process, and to make it easier to understand the fundamentals, let’s focus on the overall flow. OAuth 2.0 has an abstract, or overall, flow. Different grant types might not follow the flow all the way through, but the overall flow lays out the possible path of communication. It’s also the flow used by the authorization code grant type, which is often considered the more secure method but one that may not be possible in all uses cases.
In our example of an OAuth 2.0 flow, instead of clients and resource servers, we’ll use more common characters—you, your grandma and a videogame store to name a few—but the OAuth 2.0 fundamentals are exactly the same. We can think of breaking the overall flow into three phases to represent the key steps. The three phases can be thought of as one-on-one interactions between four characters:
- Client: You, the person trying to access a protected resource (the game)
- The resource owner: Grandma, who actually owns the game
- The authorization server: Grandma’s assistant, who helps manage purchases
- The resource server: The store where you purchase the game
You request from your grandma a form of approval that allows you access to her account to purchase a game. She agrees and gives you a sticky note with her initials written on it.
You bring grandma’s approval, the sticky note with her initials, to the assistant. The assistant recognizes that this means you’re approved to access her account to purchase the game. The assistant hands you a sheet with a barcode on it.
You take the sheet with the barcode to the store. They scan the barcode and see that you have access to grandma’s account to purchase the game. You purchase the game and out you go!
Phase I: You and Grandma (Client and Resource Owner)
This is a fairly simple process in our analogy. You ask your grandma for her approval to pick up the game from the store for her. If she accepts your request, she might give you a sticky note that she wrote her initials on. The sticky note is the authorization grant. It’s the thing that represents grandma’s approval for you to access her account.
Phase II: You and the Assistant (Client and Authorization Server)
In the overall flow, the assistant decodes that signed sticky note to verify you are allowed access to Grandma’s account in order to purchase the game. (You might head directly to the assistant if you had special credentials and your grandma allowed you to bypass her. This shortcut is allowed in some OAuth 2.0 flows.) You can now trade your sticky note in with the assistant to get a sheet with a barcode printed on it. The barcode has encoded in it what the store should allow you to do: purchase a specific game via Grandma’s store account. This barcoded sheet acts as an access token, and the assistant acts as the authorization server.
Phase III: You and the Store (Client and Resource Server)
You arrive at the store and an employee scans the barcode. It logs into the account with certain privileges, i.e., the ability to purchase a particular game. Similarly, the access token shows that the client has access to some protected resource, so the client can retrieve it from the resource server.
Your OAuth 2.0 Translation Key
We can take our creative metaphor and apply it to the maps often found when trying to learn OAuth 2.0. To help you better understand these flows, I’ve modified this common OAuth 2.0 diagram with the characters and actions from our example. I hope this helps you out as you start to think about why you should consider OAuth 2.0 for your app, and how to implement it.