Hello everyone 👋. Recently, I have been working with a lot of OIDC and OAuth stuff professionally. So, thought of writing a blog series out of several experiments we have did & have been doing with various providers & of course building our own at the moment. Now, This one will get you started with OAuth.

Introduction

If you’ve ever signed in with Google/GitHub/Facebook/… in any third-party website you might have already experienced how OAuth works.

OAuth is an open standard, which is known for access delegation. Here, delegation of access mean you authorize a certain application/a device to perform actions on your behalf. But why do we need it?

Why OAuth?

Whenever you need to provide a third party application, an access to one of your protected resources, you need to provide them with your credentials for it to access them in a traditional client-server authentication model.

But, this comes with a huge risk, if any of the applications is compromised, your credentials are also compromised along with all the data that password is protecting.

Here comes the need of OAuth, where you would delegate your access to a certain third party application without sharing your credentials with them. Woah 😳, but how? Let’s find out.

OAuth & the pieces holding it

So, how OAuth solves it. OAuth introduces a layer of authorization between the resource owner(you) and the third party application(client).

It issues certain credentials to the client, with which it can request for access to resources of a particular user. Now, instead of client making use of your credentials, OAuth will issue a string called access token, which has several attributes denoting the scope, validity & other related information.

So, if you take a close look at the framework there are four key components here,

• Resource Owner (you)
• Client (third-party application)
• Authorization server (owns your credentials, and grants access to clients)
• Resource server (server of your restricted resources)

Resource Owner

An entity, who is the owner of all the restricted resources and is the one who grants access to other applications. This can be a software or a person 💁.

Client

Entity requesting access for your protected resources, and does operations on behalf of resource owner. A client can be anything and can live anywhere i.e. on web, server, desktop etc.

Authorization Server

Entity responsible for authenticating users, clients and providing access to clients on behalf of users via access tokens. Authorization server should be the sole owner of user credentials.

Resource Server

Resource server, is where the actual resources are, and protects them using access tokens, which act as keys to unlock them 😉.

To put it all in a figure, here’s how it looks.

This is one case of OAuth, where a real user is involved. What if, a client wants to access resource of another software (kind of machine to machine communication)? Let’s explore that in our upcoming blogs. As mentioned at the start of blog, we will go through a lot of OAuth during this series. So, stay tuned. See you soon in another OAuth blog. Until then, stay safe. Cheers ✌️✌️.