Gatekeepers of the Treasure-house!
Software development is a field that has evolved over a period of time, people used various sets of technologies that were deemed the latest and greatest at the time when the development was happening, but with time everything evolves and makes way for something new and fresh. However, some of the aspects have stood the test of time and have remained as important and relevant as they were at any point in time. Best practices like various Architectural patterns, Design patterns, SOLID principles, etc. are still considered the backbone of any good quality software. Along with these, there is another aspect that everyone should be very much careful of to keep the trespassers, the hackers, and bad guys at bay and that is nothing but the defense mechanisms of the system being developed.
In this article, we will try to present an overview of the approach and the tools we have with us to make a truly secure system.
Security of the System
We can build a system and use what not available at that time but if the security of the system is compromised then whatever we have used will not come to rescue the system, so it is of paramount importance to think of having a good safety mechanism in place while the system is being designed. In that sense two things are commonly referred to and used: Authentication and Authorization, let’s spend some time understanding these two.
Authentication
It is a process where the users prove themselves to be what they claim. This is normally the first line of defense of a system. There are various ways this can be done and normally it is implemented using passwords, biometrics, one-time passwords, or one-time pins or MFAs.
Authorization
It is a process to ensure that the user trying to access a resource does really have the needed permissions, otherwise the system shouldn’t allow the user to access the resource.
With this brief, let’s jump straight on to the topic of this article which is Open Authentication shortly referred to as OAuth.
Why OAuth?
Well, we may say if we have a way to create an Account or Register to any site then what else is needed for having another buzzword called OAuth. The answer lies in the fact that we may not have trust on the site we are trying to create an Account on or sometimes (ideally this should be avoided at all costs) users end up sharing the same passwords on multiple accounts, for these and various other reasons OAuth gives us the alternative to not have Account or get into a situation where we may have to share the passwords at multiple places.
Imagine you need to build a collage of your favorite memories and want to share that with your best friend and with little googling you come across a site that offers to build collages and share that with the world but you are not sure how this site would use your profile obviously that includes user username, password, name, age, etc. What do we do now?
For these reasons nowadays the applications that offer to provide some kind of service to the users have a way that allows the users to bypass this process and that means they are OAuth compatible. Let’s dwell further into what part now.
What is OAuth?
OAuth is an open-source Authorization protocol that lets the application secure access to resources on behalf of the user. Let’s say there’s a collage building application and it allows the users to maintain the state of work and for that it mandates the users to build their profile before venturing into collage making process. It though has an integration with Facebook and allows the users the authenticate on Facebook and then the application would request Facebook to share the basic information (information that is needed to build a profile on the Collage application) back to it only if the user gives consent. This way the user can have a sound sleep of not creating an account on an application that he/she is not very sure of and of anything that goes wrong with the Collage application!
How does it work?
The OAuth specifications are not very apparent and are a bit confusing at times, we will present the details of using OAuth in a fairly simple and practical way. While talking about OAuth there are few keywords that we should understand before getting closer into the nitty-gritty of the protocol.
The Client Application
It is a third-party application that needs to get access on behalf of the user at the same time it can’t get access until and unless explicitly allowed by the user
The Resource Server
It is a server where the resources that ‘The Client Application’ needs to access are residing
The Authorization Server
It is a server that is responsible for authorizing ‘The Client Application’ to get access to the resources present on ‘The Resource Server’
The Resource Owner
It is a person who gives consent to ‘The Authorization Server’ when ‘The Client Application’ tries to access some part of his/her account
How they fit in?
The above illustration depicts the ecosystem of the OAuth and how each participant is related to others and how the coordination happens. At a high level, ‘The Resource Owner’ delegates ‘The Client Application’ to get the access token from ‘The Authorization Server’. Using this access token, ‘The Client Application’ then goes and gets the needed resource from ‘The Resource Server’.
As said this is at a very high level, now let’s get a little deep to understand what makes this flow work on the ground.
The Details
The key point in the above diagram is ‘The Client Application’ acting on behalf of ‘The Resource Owner’. But for that to happen, ‘The Client Application’ needs to register itself with ‘The Authorization Server’. The registration process involves submitting basic information like application name, website name, logo, etc. Along with these details, it also needs to provide a callback URI or a redirect URI that ‘The Authorization Server’ would use for communicating back with ‘The Client Application’. Upon submitting these details, ‘The Client Application’ will get a Client ID and a Client Secret. Client ID is public information whereas the Client Secret has to be kept secret under all circumstances preferably on the backend of ‘The Client Application’.
All this and what comes next can be understood by going over this flow
For Web-based or Mobile-based applications the next thing in line is ‘The Resource Owner’ clicking on some interface on the front-end of ‘The Client Application’ to get authenticated with ‘The Authorization Server’. ‘The Resource Owner’ is redirected to the login page of ‘The Authorization Server’. Upon submitting his/her credentials a consent screen is displayed to the user, and at this point, the user is completely at his discretion to either Accept or Deny the prompt shown on the screen. What happens under the carpet here, let’s understand.
The front-end of ‘The Client Application’ submits a request to ‘The Authorization Server’ for getting the Authorization Code. In the process, it submits the following details to ‘The Authorization Server’
- response_type=code
This tells ‘The Authorization Server’, that the front-end of ‘The Client Application’ is seeking the Authorization Code in the response - client_id
It is the Client ID that ‘The Client Application’ got upon successful registration with ‘The Authorization Server’ - redirect_uri
It is the callback URI that ‘The Authorization Server’ would invoke post successful authentication - scope
These are the values that indicate what part of the User’s profile is ‘The Client Application’ interested in - state
This is a random field that ‘The Client Application’ would verify later
The front-end of ‘The Client Application’ sends an HTTP GET request and the URL looks like below:
When ‘The Authorization Server’ receives this request, it displays an Authorization prompt and after getting the consent from the user it sends the Authorization Code back to the front-end of ‘The Client Application’ by invoking the callback URI which is submitted at the time of the registration process. The front-end of ‘The Client Application’ also receives the state in the response and it validates that with what it sent as part of the initial request. This ensures the connection is not forged between the two parties.
Now since the front-end of ‘The Client Application’ has the Authorization Code, it trades it with ‘The Authorization Server’ for getting the Access Token. The front-end of ‘The Client Application’ sends the Authorization Code to its back-end. The back-end of ‘The Client Application’ now takes charge and sends an HTTP POST request and the URL looks like below:
- grant_type=authorization_code
The grant type for web-based and mobile-based applications would be authorization_code only - code
It contains the Authorization code received as part of the previous call to ‘The Authorization Server’ - redirect_uri
The callback URI where the Access Token would be sent back to ‘The Client Application’ - client_id
The Client ID of the ‘The Client Application’ - client_secret
The Client Secret of ‘The Client Application’
The response of the above call in case it is successful yields Access Token and a time duration within which the Access Token would expire.
Now the back-end of ‘The Client Application’ with the help of the Access Token, can make a request to ‘The Resource Server’ for getting the desired resource. ‘The Resource Server’ also validates the Access Token with ‘The Authorization Server’ and post validation it sends back the resource to the back-end of ‘The Client Application’
Why 2 steps?
If we look at Step#1 of getting the Authorization Code it all happens on the Front channel. A Front channel is a channel where normally the data transmission happens over the browsers. The front-end of ‘The Client Application’ sends re-direct to the login page on ‘The Authorization Server’. Post this, ‘The Authorization Server’ makes a callback on the front-end of ‘The Client Application’, as can be seen here all of these are browser redirects. So there are chances that some can squint or oversee what’s being exchanged and therefore the credibility of the tokens being transmitted can be compromised.
For this as well as the need of keeping the Client Secret always under the confines the actual request for getting the Access Token is sent from the back-end of ‘The Client Application’ which is also called the Backchannel.
There are applications where this may not be possible like single-page apps where keeping the Client Secret may be challenging. For them, there are different mechanisms that are used that involve sending a dynamically generated secret with each request.
Conclusion
I tried to detail out some of the confusing aspects in OAuth usage although there are other grant types that are supported by OAuth specifications. But the one talked about here ‘authorization_code’ is the most widely used type of grant type. I’ll share more details around these and some other aspects of OAuth in my next!
