OAuth is an immensely popular open authorization framework available in the industry. In this oAuth tutorial, we will look into the detail concept. In this oauth tutorial understand oauth2-0 in simple step by step lesson. It demystifies all the complex technical jargon to clear the readers’ concepts.
OAuth2.0 is one buzzword in tech industry and specially in the security forums. Rightly so! it provides so much capabilities in the authentication and authorization framework. However, the understanding of this immensely popular auth sceheme is not always clear. In this blog post, I tried to put forward my understanding in simple terms.
Let’s jump to the topic directly. 🙂
NOTE:- This is a multi-blog series of tutorial. In this section, we just focused on the concept of oAuth as a whole. In subsequent posts, we will cover this topic in further detail.
Roles in OAuth2.0
To understand OAuth2.0 better, we first need to understand the various roles available in this scheme. Let’s take a look –
- Resource Owner or the user: It’s generally a person or an application who/which owns a protected resource (or data) on Resource Server.
- Resource Server: It’s the server that hosts the protected resource( or data). This data/resource is to be shared with the client/third part application.
- Client or the third party application (TPA): The client or third party application requests access to the resources/data (owned by Resource Owner) stored in Resource Server.
- Authorization Server: It authorizes the client/TPA to access the resources of the Resource Owner. Even though the Authorization Server and Resource Server have their own roles and responsibilities; they can be on the same or different servers.
So many jargons!! Did it just confuse you? Let’s take a simple example.
Understanding oAuth2.0 with simple example
You must have used Facebook. You may also have tried your hand in playing various games in FB. Even though I am not a gaming fan; back in my days, I tried some of these popular games. Coming to the topic, when you play these games, FB pops up a dialog box. It asks for your consent to share some of your user/personal information with the game application. That’s a classic example of OAuth. Now, let’s take this example to match with the jargon we just read through.
A user on Facebook is the Resource Owner. The information (like profile information) a user own is his/her personal data. The resource owner can also be an application. The OAuth 2.0 specification allows both possibilities. Now, as the user creates/hosts the profile in Facebook, so Facebook can be considered as a Resource Server. The user may want to play a particular game. However, in order to play, the game application needs to access certain information from user’s Facebook account. The game can be considered as Client or third party application. Facebook has an Authorization Server that authorizes this gaming app to access the necessary information from user’s account after obtaining the approval or user consent.
I am hopeful that now you are able to connect the dots between all these roles and how they connect to each other. A Please find below a simple depiction of different concepts that we learnt so far –
oAuth Simplistic Workflow
Take a look in the below diagram for the simplistic view of oAuth2.0 workflow.
In this post, I tried to cover the basic concepts behind various stakeholders in oAuth2.0 auth scheme. In upcoming posts, we will go through various workflows under oAuth2.0 scheme. Stay tuned 🙂
- Authorization Grant type (with refresh token)
- Implicit Grant Type
- Resource Owner Password Grant Type