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?
Ever since the Cambridge Analytica scandal is uncloaked, data privacy and security have been the talk of the town. Eventually, privacy policy update emails have been flooding all over your inbox, thanks to G.D.P.R. Giving utter importance to data privacy, I want to write about how the data is protected at the servers by preventing unauthorized access. Today, we will look into the data authorization protocol called OAuth 2.0.
Preface
Often, we face a situation where a third party needs to access our private information retained by a trusted entity. Consider a real-life scenario where a Game application needs access to your Facebook profile data kept on 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 so that they won’t misuse your credentials or other private data. The risk is that 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 scarier.
There is a need for an abstraction here. We want a solution where 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 2.0
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 -
A resource owner is someone who has their private data stored on some secured server(Resource server).
The client requests the Resource owners’ information. Generally, the Client uses this information to provide some services to the Resource owner.
The resource server hosts the Resource owner’s information securely. A valid authorization is needed to access this information.
The 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 Client so that it can access the resource owner’s information.
In our first example, the Game application(Client) requests 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 the OAuth 2.0 protocol -
Let’s find out what is happening here -
1. The Client asks the Resource Owner to authorize the Resource server to get access to the information/resource hosted by it.
2–4. The Resource owner is directed to the Authorization Server to authorize itself. Upon successful authorization, the 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 temporary access to the Resource owner’s information.
The 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. The Resource Server may get an invalid access token from the Client which fails the access token validation. The Resource server provides a failure to the Client in this case. The Client needs to refresh the access token using the refresh token. This, again, is taken care of by the Authorization Server.
The 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 -
Authorization Grant
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 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 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 mobile and web apps.
2. Implicit
This method saves the roundtrip of obtaining the authorization code to get the access token from the Authorization Server. Instead, the Authorization server directly provides the access token to the Client (once the Resource owner authenticates itself with the Authorization server). The access token can be exposed to the Resource owner. This method is convenient for the clients like the web browser running lightweight JavaScript clients, which need a better throughput. Needless to mention that security is compromised in this scenario.
3. Resource Owner’s credentials
The 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 its 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 the Resource Owner’s credentials from 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, the duration of its validation, the scope of its use, and other parameters.
The Client has to keep refreshing the access token to retain 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.