OAuth: Oh... so I AUTHorized What?
Published: 2021-01-12 19:09:46

We've all seen the authorization box pop up, but most people tend to click through quickly to get the result that they want. Here's an example of what a user sees on screen with a simple verification through OAuth which will allow [Codewars](https://www.codewars.com/) access to a given scope of data from a user's [Github](https://github.com/) account.

![login-sample](https://dev-to-uploads.s3.amazonaws.com/i/zwkjba84vb8ibfmshzqc.png)

Let's explore an example of two services interacting without [OAuth](https://oauth.net/). A user - we'll call him Jack - wants to print a photo through a printing service app but the photo is stored in another app like Google Drive. Before authorization between services was available, the only way for the printing app to get access to Jack's photo would be to ask him to log in to Google with his Google credentials on the printing service's app. 

![Blog-Img-1](https://dev-to-uploads.s3.amazonaws.com/i/3fiuf4ebzg4dygf8ewif.jpg)

**This is clearly problematic.** Not only does the printing service have access to everything in Jack's Google account, but Jack has to trust that the printing service will surely, definitely, immediately log out of his account when the service is complete. He'll also have to trust that the printing service will throw away his credentials and absolutely never do anything malicious.

Let's run through the flow again. Jack tells the printing service that he wants to use a photo from his Google account. The printing service says "Okay, let me grab the photo for you from your Google account."

![Blog-Img-2](https://dev-to-uploads.s3.amazonaws.com/i/6cfr45b6wq3n83vzqy2d.jpg)

The printing service then goes to Google and asks, "Hey Google, can you give me this photo from Jack's account?" Google says, "No, I don't know you, so I can't trust you with Jack's information, but let me ask Jack what he would like me to do".

![Blog-Img-3](https://dev-to-uploads.s3.amazonaws.com/i/shvqadatuqqx4m0qeaqp.jpg)

***This is where OAuth comes into play.*** To Jack, it appears that Google is asking for his consent, but Google is actually going to use OAuth to verify that client (the photo printing service) is authorized to access the user's data. Google tells OAuth that it needs consent from Jack to be able to give the client app access to his account.

![Blog-Img-4](https://dev-to-uploads.s3.amazonaws.com/i/wb0cxik97az7lee08ewe.jpg)

OAuth then goes to Jack for confirmation. "Hey, this printing company is asking for access to your account. Take a look at this list of things that they would like to access, and respond with your consent or rejection".

![Blog-Img-5](https://dev-to-uploads.s3.amazonaws.com/i/hie2bc7hgnwn2fzmnjnh.jpg)

Jack gives his consent with the click of a button, and OAuth sends the printing service an authorization token. 

![Blog-Img-6](https://dev-to-uploads.s3.amazonaws.com/i/13zdfel0i2ymrmgj24uj.jpg)

The printing service takes this token to Google and says, "Hey Google, can you give me this photo from Jack's account? Here is the token that says I have access to this scope of things". Google says, "Sure, let me grab that for you".

![Blog-Img-7](https://dev-to-uploads.s3.amazonaws.com/i/jq1mhe2jeifhohaoplst.jpg)

What's important here is that Jack didn't have to enter his Google credentials into the printing service. Because of that, but the printing service only received access to Jack's photos rather than Jack's entire Google account. The original purpose of OAuth was to authorize the use of one service to another without the user giving more information than is necessary. Because it is an authorization tool between services, it can also be used to verify authorization between microservices within the same app. This provides more security by compartmentalizing permissions of the data rather than storing everything in one central location.