WTH is OAuth?
Tags: oauth, authorization
Published: 2019-04-07 13:42:04

---
title: WTH is OAuth?
published: true
description: In this post, let's talk about OAuth, its different roles and terminologies and discuss its flow
tags: OAuth, Authorization
cover_image: https://thepracticaldev.s3.amazonaws.com/i/sp7fy8xlrvi7gboli158.png
canonical_url: http://bassemmohamed.me/Post/wth-is-oauth
---

Recently I had to add Single Sign-On **SSO** in a frontend project at work. I had absolutely no idea what OAuth is. I had to learn about it and here I am! Sharing what I’ve learned so far 😊

# What is OAuth
Well, let's start with the basics. OAuth stands for Open Authentication. It’s the first version, **OAuth 1.0** was designed to handle the **Delegated authorization** problem. Imagine you need to let some service *X* access some of your data located in service *Y*. Before OAuth, You would have to give the password of service *Y* to service *X*. That's bad! You are not just giving them access to some data. You are giving them full control of your account. Without a doubt, we needed a better way! ✋

That's where **OAuth 1.0** protocol came in, It handled that problem by allowing service *X* to get access to certain data in service *Y* without compromising your password. 💪

Let's start by some terminology, just to make it clear for the rest of this post. These are also different roles in an OAuth protocol.
1. **Resource owner**: That's basically you, you own the data in the resource server
2. **Client**: That's service *X*. In other words, The application that wants to access a resource in the resource server
3. **Authorization server**: This server is responsible for authorizing access to the resource.
4. **Resource server**: That's service *Y*, In other words, The application that contains the resource.
5. **Resource**/**Scope**: The requested resource. Could be some data, could be a permission to do some action. 

Note that both the authorization server and resource server could be the same application, or they could be totally different ones.


# OAuth Flow ( authorization code flow )
I created this diagram that shows the whole OAuth flow, have a quick look at it and we will go over every step after the diagram.
![OAuth Authorization Code Flow](https://thepracticaldev.s3.amazonaws.com/i/sp7fy8xlrvi7gboli158.png)

Is it overwhelming? Maybe I am not that good with diagrams 🙄. Don’t worry, Let’s take it one step at a time.

Let’s do this with an example. Let's say that you want to create a *Spotify* account, but let’s face it. You are too lazy to add all your information 😞. You want *Facebook* to fill it all for you. So you clicked on that sign-up with *facebook* button. Let’s pause here and analyze this for a bit.


What is happening here? According to OAuth terminology, Who’s whom?
1. The **resource**/**scope** is your profile information, the data that *Spotify* needs from *facebook* to sign you up.
2. The **resource owner** is you obviously 😒.
3. *Spotify* is the **client** application.
4. *Facebook* is acting as both the **resource server and the authorization server**.

Hold on! Before we dig into the diagram, OAuth depends on a one-time initial configuration step. Basically, it is a way for the auth server to identify which client app is asking for the authorization. The auth server generates a **client ID** and a **client secret**, both are unique to this client. They are then saved in the client, used in the next steps and must be kept secret.
Also, each client needs to specify a **redirect-URL**. This URL is used by the auth server during the OAuth flow.

### With that said, let's dig into that diagram.
1. **First of**, Clicking on "Sign up with Facebook" button will redirect you to a login page from the auth server. 
    * This step requires two parameters the client ID and the scope. 
    * The **client ID** is used by the auth server to identify which client is requesting permission. 
    * The **scope** is used to identify which data/permissions are being requested.
2. **After Logging in**, The auth server will display the consent screen to the user
    * The consent screen asks the resource owner if he would allow the client to have access to data/permissions defined in the scope
3. **Granting the permission**, The auth server will direct the browser to the redirect-URL passing along the authorization code in the query params
4. **Having the code**, The client would need to exchange the code and the client secret with the access token
5. **Having the access token**, The client could finally access the resource from the resource server

Super cool! But, Why do we need that extra step where we exchange the authorization code with the access token? Why don’t we just get the access token directly? **Well**, It’s a security measure, It ensures that the access token is not exposed in the params of the redirect URL.
**Ummm**, but couldn’t a man in the middle just grab the authorization code somehow and beat the client to the exchange with the token?
**No**, because this exchange also requires the client secret, which is only known by the client application and the authorization server.

This flow is called the authorization code flow, there exist other types.
Also, OAuth was misused after its initial release. That's why there was a need for OAuth 2.0 and OpenID connect. I may talk more about this In a future post.😌

If you like this blog post, please let me know. And don’t forget to spread the word!

As always,   **Happy coding 🔥🔥**
Or in Arabic…   **كود بسعادة**