Today, I am delighted to start my new series, Back to Basics. This series aims to provide basic knowledge about the technologies that developers come across in their day-to-day lives. Let’s begin today’s topic, shall we?
Often, we face a situation where the third party needs to access our private information retained by a trusted entity. Consider a real-life scenario where a Game application needs an access to your Facebook profile data kept at their servers to create a gamer profile and scan through your friend list to find out who plays the same game. A possible solution to achieve this could be that you provide your Facebook credentials to the Game application such that they can access your Facebook profile. You’ll have to trust them completely that they won’t misuse your credentials or other private data. Risk is, your private information on Facebook won’t be private again. This sounds creepy. Right?
Think of another perilous scenario where you want to make a payment to a shopping website through Internet Banking. You would provide your Internet Banking credentials to the shopping website. BOOM! A shopping website will always have your credentials and they can access all your information until and unless you change your Internet Banking password. This is even more scary.
There is a need for an abstraction here. We want a solution where a sensitive data like username and password is not shared with the third-party applications (Game application/ shopping website) and they still are able to access some data which we want them to. OAuth to the rescue.
OAuth has some history behind it. OAuth 1.0 was the first version to acknowledge this problem. Over the years, the community found it to be limited and hence introduced the new drafted version of it as OAuth 2.0 with clearer responsibilities and wider support. OAuth 2.0 is not backward compatible though.
To understand this protocol we need to be clear with the actors –
- Resource owner is someone who has its private data stored on some secured server(Resource server).
- Client requests for the Resource owners’ information. Generally, the Client uses this information to provide some services to the Resource owner.
- Resource server hosts Resource owner’s information securely. A valid authorization is needed to access this information.
- Authorization server is a trusted companion of the Resource server. It knows how to authorize a Resource owner. It can also provide a grant to the Clients so that Client can access Resource owner’s information.
In our first example, the Game application(Client) requests the access to the information stored on the Facebook server(Resource server). The Facebook user(Resource owner) authorizes itself with the Authorization server. Once authorized, the Authorization server provides an access to the information to the Client.
Following is the abstract flow of OAuth 2.0 protocol –
Let’s find out what is happening here –
1. The Client asks Resource owner to authorize with the Resource server to get an access to the information/resource hosted by it.
2-4. Resource owner is directed to the Authorization server to authorize itself. Upon successful authorization, Authorization server provides a grant to the Client.
5-6. The Client provides this grant to the Authorization server to get back the access token.
7-10. This access token is then provided to the Resource server. The Resource server validates the access token and if valid, provides a temporary access to the Resource owner’s information.
Authorization server also provides the refresh token along with the access token in step #6. The access token is time-bound. It needs to be refreshed after the specified time interval. Resource server may get an invalid access token from the Client which fails the access token validation. Resource server provides a failure to the Client in this case. The Client needs to refresh access token using the refresh token. This, again, is taken care by the Authorization server.
Following diagram depicts the complete OAuth 2.0 flow –
This is a generic OAuth 2.0 flow that most of the Client follows.
There are three things in the above diagram, which play an important role throughout the OAuth 2.0 lifecycle. Authorization grant, Access token, Refresh token. Let’s look into them –
It is an entity obtained when the Resource owner authorizes itself with the Authorization server. Authorization grant can be obtained mainly in four ways –
1. Authorization code
The Client redirects the Resource owner to the Authorization server for the authentication. Once the Resource owner authenticates itself, the Authorization server redirects the Resource owner back to the Client with the authorization grant. Due to the direct communication of the Resource owner and the Authentication server, the Resource owner’s credentials are not shared with the Client. This maintains the security. Also, the authorization grant is directly provided to the Client and hence not shared with the Resource owner. This mechanism is mostly used by the mobile apps and the web apps.
3. Resource Owner’s credentials
Resource owner’s username and password can be used by the Client to obtain the access token from the Authorization server. This needs a high rate of trust between the Client and the Resource owner. An organization’s mobile app (the Client) and their servers (Resource server) can effectively follow this approach.
4. Client credentials
Sometimes, the Client can use its credentials to obtain the authorization grant. It might sound similar to the #3 (Resource owner’s credentials) but the differentiation here is, in reality, the Client may need to access its own private resource hosted at the Resource server. In this case, the Client itself behaves as the Resource owner.
Access Token & Refresh Token
As we saw, the access token helps prevent Resource owner’s credentials being shared with the Client. It represents the string form of authorization of the Resource owner to the Client to access the information stored at the Resource server. The access token is generally a cryptic formation of the Resource owner’s credentials, duration of its validation, the scope of its use and other parameters.
The Client has to keep refreshing access token to retain the access to the Resource owner’s information. The refresh token, generally, is another string formed entity based on the access tokens being received from the Authorization server.
This is the basic information you need to know about OAuth 2.0. In the next blog, we will look into the case study of how OAuth 2.0 flow is implemented in the restricted environments where the Client can not redirect Resource owner to the Resource server for authorization on the device on which the Client is running.