Almost all the people in the world have either a Facebook or Google account or both. And I’m pretty sure that almost all that people have enjoyed where some website ask for login using Facebook or Google account to access resources owned by us (according to our grants). But in this scenario, we can clearly see that we provide the password and username to Facebook or Google. But not for the asking website. We don’t give our credentials to the asking website or app, but still, they can access data that we gave permission to them. How is that possible?
Most of the times, the asking website or app(from now on we will call it as the client), will say that they are going to guarantee the confidentiality of your credentials. But we don’t give them our precious credentials, simply because we can’t trust them. How does it feel, if some unknown person somehow has your bank pin card number without your knowledge even though you know that he/she can’t access it without the ATM card ?. Well, I’m pretty sure anyone will feel a little bit uncomfortable over that kind of situation.
In websites too this is the case. We shouldn’t give our credentials to the the Internet just because they want it to do the task that we ask for them. So what is the way to delegate a temporary authorization for given resources granted by us to that site or app?
This is where OAuth 2.0 comes.
OAuth 2.0 is an authorization framework. It will give chance to us to give permission to client website or app to access our Facebook friend list or Gmail contact list with limited access granted by us. In more technical terms what it does is that it enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account.
Let’s take a scenario parallel to the above sequence diagram.
If we want to login to Facebook from our what do we do?
First, we will ON our laptop, then we will open a web browser and will type www. Facebook.com or just “facebook” in your default search engine or simply in the address bar.
Then we will enter our credentials and will log into our Facebook account. This is the sequence “Enter URL” means in the above diagram.
Then let’s say there is a funny app saying that it will show which character you are in Game of Thrones. But when you click it you will be asked by the app saying it needs to access your profile picture, your friend list and so on. As you are a such a big “GOT” fan you allow it and suddenly you will be popped by a login page by Facebook for our credentials to authenticate and authorize. Why is that?
This is because to access our resources(profile pic, friends list etc.) the client needs authorization for that. So when you accept client’s terms it will redirect you to the authorization server to give some kind of temporary authorization only to access those. That’s why you will be sent to the authorization server. Sometimes both resource server and authorization server can be the same server.
Ok. when we enter our credentials again and they will be verified and will return an authorization code back to us. This authorization code will be created by the authorization server. So this means that the authorization server will provide an authorization code back to the web server. And it will be given to the client by the web server.
Then the client will again give to the authorization server saying “Here, I have this authorization code that my user has provided me after he/she made it from you. So could you please give me an access token to access his/her resource in facebook server.” in HTTP. So then authentication server will provide an access token to the client and client will use that token to access the resource server to get the information that it needs to provide the service that it promised to provide you.
Above is the brief description of how OAuth works. But we have to identify how this is more secure than other cookie ways or direct granting ways. To do that let’s understand what a token means.
Tokens are random strings generated by the authorization server and are issued when the client requests them. Simple as that. Without a good token handling system, those tokens are worthless. But there are token handling system and things are really interesting due to that.
There are 2 types of token:
Access Token: this is the most important because it allows the user data from being accessed by a third-party application. This token is sent by the client as a parameter or as a header in the request to the resource server. It has a limited lifetime, which is defined by the authorization server.
Refresh Token: this token is issued with the access token but unlike the latter, it is not sent in each request from the client to the resource server. It merely serves to be sent to the authorization server for renewing the access token when it has expired. For security reasons, it is not always possible to obtain this token, obviously. Think of our client “GOT” app. What if it can always refresh it’s token that we gave and can always access our profile??
Since the client wants to retrieve data from a resource server using OAuth2, you have to register as a client of the authorization server.
Each provider is free to allow this by the method of his/her choice. The protocol only defines the parameters that must be specified by the client and those to be returned by the authorization server.
Before using OAuth 2.0 with the client, the client must register itself with the service. This is done through a registration form in the “developer” or “API” portion of the service’s website, where you will provide the following information (and probably details about your application):
Redirect URI or Callback URL]
In the Flow above that we discussed, the first steps cover obtaining an authorization grant and access token. The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the API. OAuth 2.0 defines four grant types, each of which is useful in different cases:
Authorization Code: used with server-side Applications
Implicit: used with Mobile Apps or Web Applications (applications that run on the user’s device)
Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
Client Credentials: used with Applications API access.
So above article will provide a good starting point to this authorization framework. And to have a deeper knowledge about above scenarios Follow this article.