OAuth 2 Overview

OAuth 2 has become the de-facto standard by which authentication and authorisation are done on the internet. An entire industry has spun around it with players like Auth0 offering SAAS solutions, every major company with a user base offering login with Google/Facebook/Twitter/etc., and companies offering to build you a better experience if you give them access to your data on these platforms.

Like with many ubiquitous things, OAuth 2 has become a building block we put in an opaque box and don’t think much about. In this post, I want to dig into some of the terms associated with OAuth 2 and shine some light on that box.

Origins of OAuth

The first thing to understand is the problem that OAuth was created to solve. Before OAuth, when a user wanted Service A to interact with Service B on their behalf, they'd need to give the username and password that they used to access Service B to Service A. They'd be trusting Service A to act as them, with the full power to do anything that the user themselves could do. In concrete terms, you'd provide your G-Mail credentials to Facebook and trust that they'd only use it to invite your friends to connect with you. Trust that Facebook wouldn't read all your data.

OAuth was invented to provide a way for a user to provide a subset of their authorisation without giving up complete control. Now you could give Facebook access to your G-Mail contacts and not any of your email contents, a win for the users.

Components of OAuth

Resource Owner

The party sharing its authorisation to access, modify or invoke an API on the Resource Server. This will often be a user but could also be a server in the case of machine-to-machine communications.

Resource Server

The party hosting the API that controls access to the data or functionality being requested. This is the party that will evaluate the granted credentials.

Client

The party that is requesting credentials.

Authorisation server

The party that is issuing the credentials. This could be the resource server, but most often is a separate system.

In the example above with G-Mail and Facebook. You, the user are the Resource Owner, G-Mail is the Resource Server, Facebook is the Client, and Google Authentication is the Authorization Server.

Tokens

The way that authorisation is represented in OAuth 2 is as a JWT, JSON Web Token. The high-level overview of these tokens is that they comprise three sections separated by a .. The first two sections (the head and body) are base 64 encoded JSON objects. The third (the signature) is a base 64 encoded signature generated from the first two sections.

The head contains information about how the token is signed and where to find the key that can be used to prove the Authorization Server issued it.

The body contains all the information transmitted in the token. There are some guidelines about what should be included in the body, but it is largely free form.

The signature is an encrypted hash of the body and the head. Signing the token means that any party presented with the token is confident that the Authorization Server issued it.

Flows

The Authorization Server and Client communicate securely by following one of the Flows outlined in the OAuth 2 specification. These Flows establish the protocol of redirects and API calls that establish trust between the parties.
Each of these flows deserves its own post. In short, there are 6 (and a half) Flows:

• Authorization Code; Used when exchanging authorisation and authentication information on behalf of a user. ** Authorization Code with PKCE; Used when exchanging authorisation and authentication information when the client cannot store secrets securely. e.g. Web and Mobile clients.
• Client Credentials; Used in machine-to-machine authentication. Authorising between two servers that can communicate secrets securely.
• Device Code; Used when authenticating users when the user is using an input-constrained device such as a smart television.
• Refresh Token; Used when exchanging a refresh token for a new access token.
• Implicit Flow. Do not use. Previously used for authenticating users, it has been deprecated due to security issues.
• Password Grant; Do not use. Previously used for authenticating users, it has been deprecated because it required the client to have the user enter the user's username and password.

Open ID Connect

Lastly, I want to mention Open ID Connect, commonly known by its abbreviation OIDC. OIDC is an extension to OAuth 2 that allows for the exchange of user authentication information between the Authorization Server and Client in addition to authorisation. OIDC enables OAuth to go from the use case of "Sharing your G-Mail contacts with Facebook" to "Login with Facebook".

This post has only briefly touched on a range of things in the OAuth 2 space. There is a lot of room to go deeper into each of the Flows, tokens and, of course, OIDC.