OAuth: a quick overview

OAuth is by far the most widely used authorization protocol in web applications. If you are part of this world of integrations, it is practically impossible not to have dealt with it. That's why I decided to create this content and share some of the immersion I've done over the last few months. 

What is OAuth?

It is an authorization protocol where, in a simple and standardised way, it allows the client (applications) to access a protected resource on behalf of the user. It is a security framework that describes how to grant access to user data in an application, through the HTTP protocol.

Roles

These are the roles that each entity will have during an authorisation flow. The main ones are:

• Resource Owner: Entity capable of authorising access to a protected resource. If it's a person, it can be called an end user.
• Resource Server: Server that hosts the protected resources. For example an API.
• Authorisation Server: Or OAuth Server, is the server that provides access to a protected resource on behalf of the user. This is where flows are validated and tokens generated.
• Client: Application that wants to access the resource owner's private resources.

Grant Types

These are the authorisation flows used to authorise a client to access the resource server's private resources on behalf of the resource owner. In OAuth 2.0, 4 grant types are covered:

• Client Credentials;
• Authorisation Code;
• Implicit Flow;
• Password Grant.

Bearer Tokens

It is a type of access token. It is an opaque string, i.e. without self-contained information. It can be passed via header in a HTTP request (most common form). If the POST method is used, it can be passed in the body of the request, or if the GET method is used in the query string. Ex token: c0ce7f40-e12b-393e-bb7c-5ad1fc3c9841.

JWT

JSON Web Tokens are not only a type of access token, they are also a string. However, it differs from the bearer token in that it contains self-contained information and must be signed and encrypted. It is a transparent token. It is structured in 3 parts. The header, which informs the encryption algorithm used and the type of token. The payload, which is the data itself, where relevant (claims) and never sensitive information is passed, and the draught which is where it is verified and signed. See the example below:

OAuth 2.1

OAuth 2.0 is from 2012 (RFC 6749), and a lot has changed since then. Popularisation of javascript, various types of attacks, injections and forms of interception and much more. Therefore, some changes were needed and that is why there is the OAuth 2.1 project (RFC pending at the time of this publication). The main changes are:

• Authorisation Code Flow with PKCE (RFC 7636)
• Discontinuing Implicit and Password Streams
• Do not pass the token in the query string (only in the header or body of a POST)

So to put it, the OAuth 2.1 grant types are Client Credentials and Authorisation Code + PKCE. And the token (either opaque or transparent) should be passed only via header or in the body of a POST request:

In the second part we will see how the Client Credentials and Authorisation Code + PKCE flow works, which flow is recommended to use for a certain type of application and more. 

Thanks for reading and see you soon!

‍