Hello everyone! OAuth has been a buzzword for quite some time now and it is hard for a beginner to learn it, not because OAuth is hard, but because of the confusing facts found about OAuth in the web. So I wrote this article to explain why and how OAuth is used in very simple terms! :)
So before diving right in, let’s go back in time and look how users were logged into a system. This is the most basic and simple login system, where the users' credentials are stored in a managed database(passwords are usually hashed). When the user logs in, the credentials are sent across and if credentials are successfully matched, a session is stored in the browser for reference.
- Security Issues: You must make sure user data is stored in a secure manner and it complies with GDPR( https://eugdpr.org/ ) and if best practices are not followed, the system is vulnerable to attacks.
- Maintenance: Should make sure the system is functioning (should manage servers)
The simple login show above has nothing to do with how OAuth works but I just mentioned it so that you guys have a clear understanding of what we can compare OAuth with.
The Delegated Authorization Problem?
Delegated authorization is giving applications permission to access data from systems managed by someone else. Implementing this without acquiring the users' credentials is a problem and is known as the delegated authorization problem!
For example: If we consider PUBG (which is currently a trending game), it wants to access your Facebook friend list and profile and if the app asked for your credentials in the following manner is it correct?
The answer is obviously NO! Will you trust the application and give your Facebook credentials knowing the app will be able to do more than just getting the friend list and profile? Just think about it!
Anyways, OAuth is here to save the day and solve this problem!!!
What is OAuth?
OAuth (Open Authorization) is an open standard for token-based authentication and authorization on the Internet. OAuth, allows an end user’s account information to be used by third-party services, such as Facebook, without exposing the user’s password.
If you still don't get it don't worry, I will be going step by step on how it works!
If you search for OAuth online, what you would see is OAuth2.0 showing up. This is because OAuth 1.0 is now deprecated and is rarely used. So I will be talking about OAuth 2.0 from this point onwards.
Authentication vs Authorization
OAuth 2.0 is built for Authorization purposes and not Authentication, so it important to understand the difference between these two terms very clearly.
You could go ahead and Google for these terms and find out their definitions, but after reading it, you still might not have a clear idea. So I will use this example to covey the idea:
Just imagine you are flying off to Paris with your girlfriend for a romantic holiday! When you go through the airport, the airport security/immigration officers will check for your passport and ticket to check if you are the person who you say you are(checks your identity). This is authentication!
Afterwards, when you and your girl board the plane and if the boarding pass states that you are a first class passenger, the privileges you get inflight will be more than an economy class passenger. This is authorization!
Likes wise, if we consider a real web application, keeping track of the identity of the person using the application is handled by authentication and the privileges the person has (eg: only view access or view and edit access) is handled by authorization.
OAuth 2.0 Terminology
Alright! Now let's start to explore OAuth2.0 step by step! For you to understand the rest of the article well, it is important for you to get familiarized with these terms used in OAuth2.0, These terminologies are mostly names given to already existing terms so it is not too difficult to understand.
- Resource owner: The application user, who owns the data the application wants to get
- Client: The application
- Authorization server: System that can be used to prompt and grant permissions
- Resource server: The system that holds the data
- Authorization grant: The thing that proves the user has given permission to access data
- Redirect Uri: The place the user gets redirected to when permission is given
- Access token: The key used to get the data from the resource server
- Scope: The thing that defines the level of permissions the application has to manipulate the users' data
If you have gone through the sequence of steps shown below(in any mobile or web application), where you grant permission to access your data, you have already used OAuth2.0!
Now let's break it down and see what happens under the hood to make this flow possible and get access to your data!
NOTE: The Steps are labelled in yellow, so you could refer the diagram while reading the steps!
Step 1: Starting the flow
When you register your app with Facebook or any other OAuth2.0 providers, you will get a client id and a client secret (client secret should be stored safely and not reviled to the public).
When the PUBG user clicks on the ‘Login with Facebook’ button in the app, the user will be redirected to the login page of the OAuth2.0 provider (in this case, the Facebook login page). This is made possible by sending a HTTPS request to the authorization server endpoint with the client id and a few other attributes as params. Shown below is an example :
As stated before, the redirect_uri is the place the user gets redirected to when permission is given and client_id is what you get from the OAuth2.0 provider.
The scope defines the level of permissions and these scopes can be obtained by the documentation of the OAuth2.0 provider.
For example, take a look at Facebook's scopes (the valued box in red are the scopes used in the above request)
Step 2: Giving Consent
After the user logs in successfully, the user will be prompted to give consent to let PUBG access the user's data! (the friend list and profile)
Step 3: Callback
If the user does not give the consent to access his/her data, the callback will look as follows:
The user will be redirected to the app, to the app login screen and the flow will end! PUBG will not be allowed to access the user data in that case!
error_description=The user did not consent
On the other hand, if the user gives consent, the callback will look as follows:
The callback will have the authorization code which can be used in the next step
Step 4: Exchange code for an access token
Once you get the Authorization Code from the previous step, you can send it back to the authorization server and get the Access Token
Step 5: Accessing data
The access token which is received is used to get the data required for your application, in the case of PUBG, to access the friend list and user profile
More OAuth 2.0 Terminology
You guys might be thinking, why there are two steps to get the access token (First getting the code and then again sending the code to get the access token). There is a reason why this is broken down into two steps, to understand that, you guys must be aware of the following terms :
- Back channel: Highly secure server to server communication channel
- Front channel: Less secure browser/mobile app to the server channel
Because of the security in the back channel, it is a good medium for the access token exchange to take place.
NOTE: The flow explained above is one of the several possible flows of OAuth (Authorization Code Flow), For more info visit: https://www.drupal.org/node/1958718
Also, note that I took PUBG just as an example and this might not the be the exact way PUBG handles Auth!
Hope you got an idea of how OAuth works and why it is needed. Now it’s time for you to go explore, find out more about the other OAuth flow types as well. Good Luck and have fun!
Thank you for following this article and hope it helped you! Please do buzz me if you want any help: firstname.lastname@example.org