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.
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.
These are the roles that each entity will have during an authorisation flow. The main ones are:
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:
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.
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.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:
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!