Want to know how OAuth 2.0 works? Read on and find it out.
This is a series of blogs exploring OAuth and OIDC:
OAuth 2.0 Explained in Simple Words - Part I: What and Why
OAuth 2.0 Explained in Simple Words - Part II: OAuth 2.0 Flows, Authorization Code Flow and Client Credentials Flow
OAuth 2.0 Explained in Simple Words - Part III: OAuth 2.0 Flows, PKCE Flow
OIDC Explained in Simple Words - Part I: OIDC as an OAuth 2.0 Enhancement
OIDC Explained in Simple Words - Part II: OIDC as an Modern SSO Standard
First, before we dive in the nitty gritty of OAuth 2.0, it's very helpful to have a brief understanding of why OAuth was created.
1. Issues Before OAuth?
OAuth (Open Authorization) 1.0 was invented in 2007 to fix the above issue and later in 2012, OAuth 2.0 was published to fix some critical issues in OAuth 1.0. Note OAuth 2.0 is not backward compatible to OAuth 1.0. Also, OAuth 2.1 is being drafted to consolidate the functionality in OAuth 2.0 and other new usage patterns.
So what causes the invention of OAuth protocol? The OAuth protocol was invented to solve the problem of privilege delegation. Let's first look at an example to understand what privilege delegation is.
As in the below diagram, a user wants to use an Email Management Application to manage his two email accounts so that he doesn't need to login each email account separately. In this case, the Email Management App will need to access his two email accounts (Gmail and Yahoo Mail), but question is how.
In the old days, the user will need to give his username and password for each of the two email accounts to the Email Management App, so that the app can login and retrieve emails from those two email providers. This is obviously NOT a good way considering user privacy and security. For example:
Password could be breached,
User doesn't know whether the Email Management App is doing other things rather than just retrieving the emails
When the password of Gmail and Yahoo Mail is updated, the user needs to update the password information in the Email Management App as well, which is difficult to maintain when the user has more email accounts
When the above problem became prevalent online, some internet standard organization started to design a protocol to fix the issue.
2. How OAuth Fixes the Issue
The genius idea here is to add another entity or party (Authorization Server) to the above diagram (see below).
An Authorization Server is added to the flow and in this case, the user doesn't need to give the credentials to the Email Management App anymore. Why? Because the Authorization Server will issue a token (called Access Token) to the Email Management App and the app will use that token as credential/proof to access Gmail and Yahoo Mail. Of course, the Access Token needs to be verified.
So instead of exposing the personal password to the Email Management App, the end user authenticates into Authorization Server. Then the question is why is this a better situation? As you are still exposing the personal password to the Authorization Server.
From a view with a larger scope, this Authorization Server is usually not some random server, but rather one with Authority in a given context. For example, in a company's internal network, the company can establish a formal Authorization Server for all OAuth related flows and in this case, we can trust this Authorization Server within the scope of the company's internal network.
Furthermore, another crucial benefit is that when the user authenticates to the Authorization Server, he could just use one user account (such as his company credential) for accessing different Applications. Here we are talking about the Email Management App, but in the real world, there could be hundreds of apps like this and they can all rely on this Authorization Server with the one user account for each user.
As you can see, the critical part is the introduction of the Authorization Server that changes the privilege delegation game and this is why a lot of times, people will say OAuth is a delegation protocol.
3. Some Terminology
Note Resource Owner, Client, Authorization Server and Resource Server are the four main roles in the OAuth 2.0 protocol and we will talk more about them later.
JWT - A JWT (JSON Web Token) is a method for representing claims securely between two parties as defined in RFC 7519.
Resource Owner - The end user who owns some resources (e.g. The user owns Gmail and Yahoo Mail accounts)
Client - An application that will access protected resources (e.g. Email Management App)
Authorization Server - The server that issues Access Token
Resource Server - A server that hosts protected resources (e.g. Gmail server and Yahoo Mail server)
Access Token - A self-contained string used to access protected resources. JWT Token is most popular. In the pic below, left side is a JWT token and right side are decoded values.
Grants - Different workflows to get Access Token
Scope - A way to limit the amount of access to the protected resources
4. Roles and High-level Workflow
Understanding roles will help us to better understand OAuth 2.0.
There are four roles in OAuth 2.0: Resource Owner, Client, Authorization Server and Resource Server, as shown below.
Let's look at the OAuth 2.0 workflow at a high level.
The OAuth 2.0 workflow starts with the end user (Resource Owner) trying to use Email Management App (Client). In order for the Email Management App to work or fulfill its functionalities, it needs to access Gmail and Yahoo Mail server (Resource Server) for the user's email resources. However, without proper credentials, the Email Management App just can't access those resources, as they are protected. The credential that the client needs is the Access Token and in order for the client to get the Access Token, the client redirects (usually a browser http 302 redirect) the user to Authorization Server, where user will get authenticated. Note OAuth 2.0 standard does NOT specify what kind of authentication method to be used, so any method that suits the context will be fine. This is another reason why people say OAuth 2.0 is a Delegation Protocol, but NOT an Authentication Protocol.
After user is authenticated, the Authorization Server might present a consent page asking the user whether the user will give the listed permissions to the Client App to access the resources. Below is an example. The workflow will be terminated if user chooses deny or cancel.
This consent page is NOT required in the flow. Many Authorization Server supports 'implicit-consent' mode so that only user authentication is required.
After user authentication and optional consent is finished, the Authorization Server will return an Access Token (The Access Token in practice is usually a JWT token, but it doesn't have to be) to the Email Management App (Client). Then the Email Management App sends request to the Gmail Server (Resource Server) with the Access Token telling that it needs those emails the end user (Resource Owner) possesses. The Gmail Server checks the request and verifies the Access Token. After that, the Gmail Server returns those resources to the Email Manage App and the workflow is finished.
One thing to mention is that the OAuth workflow doesn't have to involve a user. In this case, the client triggers the OAuth 2.0 flow by itself and will get an access token for its own usage. This is often named as machine-to-machine call.
From an even more abstract view, the whole point of the workflow is to get an Access Token from the Authorization Server so that the client can access the Resource Server for the protected resources.
Please also note, this is just a high-level process of the OAuth 2.0 workflow and in practical situation, there are more details and tweaks going on.
5. Sum Up
In this post, we talked about the privilege delegation issue from the history of internet and web technology, which causes the creation of OAuth protocol. Then we looked at how OAuth protocol fixes that issue and some key terms of OAuth 2.0. Then, we went through the OAuth 2.0 workflow at a high level.
You can continue reading in the OAuth 2.0 Explained in Simple Words - Part II