Since the beginning of internet, it’s been tough for people to keep a track of their passwords. They either forget them or use the same password everywhere. This is where oauth enters, which provides users a safe way to access services without entering their passwords. How? Let’s understand what is oauth and how it works through this article.
Before diving deep into OAuth let’s understand 2 words clearly i.e. Authentication and Authorization. There’s a lot of confusion around this and it will be a good idea to make it clear before going through the article.
Authentication: This is when a user proves their identity by either password, tokens, etc.
For example: When you enter the airport you are asked for an official Govt. Document to prove who you are claiming to be.
Authorization: This is when a user is given certain roles and permissions which is associated with limited access to resources, actions, etc.
For example: There are certain rooms and places in the airport that normal citizens are not allowed to enter. It specifically requires an ID card, etc to enter.
Overview of OAuth 2.0
OAuth stands for ‘Open Authorization’, it’s an authentication and authorization framework that allows applications, RESTful APIs, Microservices etc to gain limited to full access to certain resources which otherwise is only possible when users themself request it.
It’s like someone is carrying out an operation on your behalf. Let’s look at some use cases to understand this better.
Use Cases of OAuth 2.0
We as users go through the process of OAuth 2.0 on a regular basis. Let me point some of them out:
So you listen to your favorite music on Spotify, there are high chances that you must’ve used Login With Google or Login With Facebook as the option rather than typing your id and password.
Let’s deep dive here to understand what happens, for the sake of example, I will be considering Google as the OAuth 2.0 provider
Spotify sends an authorization request on your behalf to Google.
You see a popup from Google that mentions all details Spotify is requesting and whether you want to allow Spotify to access that or not.
Once you allow it, google sends an authorization grant to Spotify which is used later to authenticate itself to google.
Spotify sends this Authorization Grant to Google, post verifying the authenticity of the Authorization Grant Google sends the Access Token.
Now, Spotify uses this access token to request information like basic user details i.e. name, gender, age, etc from google
Google checks the access token’s validity and shares the requested details
And that’s how your Spotify account got created and you are now logged in!
Here’s a flow diagram of the steps explained above:
Similarly, there are a dozen other applications like Quora, Uber, Instagram, etc that use OAuth 2.0 to onboard their users.
Oauth Roles
Let’s look into each component and their roles in Oauth 2.0 –
Application – This is the systems that needs access to the user’s data. It must be authorized by the user and should have a valid access token.
Resource Owner – This owns the user’s data and can grant access to it.
Resource Server – As seen in the above diagram, resource servers accepts an access token, validates it, and returns desired resources.
Authorization Server – This receives request from the application for access tokens and grants it after successful authentication from the resource owner.
OAuth 2.0 vs OAuth1.0
OAuth 2.0 is the successor of OAuth 1.0, so its obvious that it has filled some gaps that were there in OAuth, additionally focused on ease of usage. Let’s discuss some of these points:
Comparison of User Experience And Security Attributes
1. Support for All types of applications
OAuth 1.0 only supported browser applications, therefore desktop and mobile applications had to redirect user to browser to complete the authentication and get back the tokens.
OAuth 2.0 solves this problem because it has a different authorization flow that is initiated by these applications.
However, when using OAuth 2.0 with non-browser base applications it is advised to follow the best practices from https://tools.ietf.org/html/rfc8252
2.Easy Implementation
OAuth 1.0 validated the exchange of data between client, server and resource server with the help of a shared secret. This secret was also used to sign the authorization request made by client and the server signed with the client’s key to validate the legitimacy of the exchange. Since this dealt with a lot of exchanges of keys it faced a lot of criticism for implementation by developers.
OAuth 2.0 has given the major security responsibilities to the way HTTPS operates, it can only be implemented where SSL and TLS are made available. It uses the privacy properties included with TLS communication.
Comparison in a nutshell
| OAuth 1.0 | OAuth 2.0 |
| It is transport-independent i.e. it does not carry out authorization with SSL / TLS but rather follows some different protocol. | It is transport-dependent i.e. SSL / TLS plays a major role from the security perspective. |
| Uses digital signatures for authenticity and integrity of messages ensuring tight security. | Uses bearer tokens, JWT for security, which is not great as they do not have internal security mechanisms. |
| Difficult to implement. | Easy to implement. |
| Not flexible as it only handles web-flows or browser based applications. | Much more flexible as it considers all non-brwoser based applications. |
| Tightly coupled as only one server is responsible for authorization and resource sharing. | Decoupled as resource requests and user authorization are handled by different servers. |
| Access Tokens are long-lived in nature and could be stored for a year or more. | Access Tokens are short-lived, and refreshed in regular interval of time. |
Can I use OAuth 1.0?
It is not advisable to use OAuth 1.0 because a lot of resource providers like Google have completely moved to OAuth 2.0. There are still some providers like Twitter that completely support OAuth 1.0
Steps to use Google APIs with OAuth 2.0
Google APIs like maps, translation, calendar, people, etc use OAuth 2.0 protocol for authenticating and authorizing requests. To start using these APIs you need to create OAuth 2.0 credentials from Google Cloud Console.
Let’s take a look at the 5 steps that needs to be followed to access Google APIs with OAuth 2.0:
Create OAuth 2.0 credentials
Open Google API Console to create the relevant credentials such as Client ID and Client secret, etc depending on the application you are using. Google and your application store these secrets.
Create an access token
You need an access token to access the private data, this token is created with the help of credentials from step 1.
A request is sent from your application to Google on behalf of you. Google then shows the user a list of permission the application is requesting for.
These permissions are defined under a parameter called scope.
Once the user grants any one of the permission, Google returns an Access Token and a list of scopes where this token is valid. Google returns a server error if none of the permission is granted.
If your application needs multiple permissions, it is a best practice to request for permissions eventually, this is known as Incremental Authorization.
Scope Examination of access permitted by user
The scopes listed in the access token response is compared with the scopes required to access resources via specific google APIs.
For instance, the user receives access token to read resources from people API. But if the user tries to update a contact with the same token this request fails; as the token’s scope doesn’t matches the requesting scope.
Send the access token to the API
After receiving the access token, it is sent to a Google API in HTTP Authorization request header. It is advised to share this token with headers only and not via query params; as these requests are usually stored as logs.
Refresh the access token, when needed
As mentioned in the comparison above, access tokens of OAuth 2.0 are short-lived and your requests will fail once these tokens are expired.
Along with the access token, Google provides us a refresh token. This refresh token is used to create new access token which should replace the expired one.
OAuth 2.0 in Microservice based architecture
In distributed systems, service-to-service (microservice) communications happen very frequently. These communications need to be authenticated and authorized. Some oAuth providers such as Google provides this facility. This needs a service account which is different than that of an individual account. We will take a look at the steps to create.
Creating a service account
Open the Service accounts page.
Select an existing project, or create a new.
Click + Create service account.
Fill in the details under Service account details for the service account and proceed.
We can also grant the IAM roles to this service account from Grant this service account access to project section. Note: This step is optional.
Click Continue and Done to complete the steps..
To use the above service account we need to have a key, following are the steps to create one:
Click + Create key, then click Create
Choose the email address you want to associate with the service account you created.
Click the Keys tab.
Select Create new key from the Add key drop-down list.
Click Create.
With this we will have the public / private key. Store the private key carefully, as if we lose it there will be no way to recover it other than creating a new one by following the above steps to create one.
Use appropriate and official libraries from Google to make authorized API Calls.
Wrapping Up
In this article we learned about OAuth, its security attributes, its working and why its a good choice to use to secure our RESTful APIs, Microservices, applications, etc.
Although it may be complex to implement, it takes care of the complete authentication and authorization module for your projects. You can easily decouple the authentication module from your system and not to mention the industry standards that you would be following with OAuth.
To understand more about Oauth and how it can increase your chances towards building a successful company, schedule a free consultation with our team of qualified cloud engineers.