Technical blog: Accessing Google Drive API Using OAuth 2.0

Accessing Google Drive API Using OAuth 2.0 + JavaScript + NodeJS

Previously, I explained two ways of protecting a web application from CSRF attacks. In this blog post, I will explain about another authorization mechanism called OAuth. OAuth stands for Open Authorization Protocol. The latest version of this protocol is 2.0. OAuth 2.0 provides users with the ability to grant third-party access to web resources without sharing a password.

OAuth 2.0 - What is it?

OAuth acts as an intermediary on behalf of the end user, providing the service with an access token that authorizes specific account information to be shared. Let’s take a simple real-world scenario. When we apply for a bank loan, the bank requires one or more guarantors to guarantee us.

The reason for that is, even though we want the loan the bank doesn’t know us. So the bank wants someone to recommend me to the bank as a trusted person. The person or the people who recommend us to the bank is/are called the guarantor/guarantors.

Before diving deeper into OAuth 2.0, it is important to understand what the following keywords mean.

Authentication — validating if the person is who he says he is.

Authorization — what actions a person is allowed to perform when he/she has been authenticated.

OAuth 2.0 provides,

Federated Identity — Allowing users to log in to an application with another account.
Delegated Authority — Allowing another service to access resources on another service on behalf of the user.

The same scenario happens in OAuth as well.

The Flow

Before OAuth 2.0, if an application wants to access your data from another application, you have to provide your account credentials, from which the data is to be accessed, to the application who wants to access the data. For example, if an application wants to suggest you your friends from Facebook you will have to provide your credentials of Facebook and then the said application will impersonate you and handle your Facebook account. Not to forget, this gives them full control of the account. That application may even store your credentials. In a time where data security is crucial, we cannot simply trust the applications. Therefore they needed a protocol to do this without compromising user’s data safety.

OAuth 2.0 overcomes this. If an application, let's say its called ‘Sample App’, wants to access your friend list, Sample App will ask if you can permit them to access your Facebook friend list. If you grant permission, you will be redirected to a page prompt by Facebook informing you that Sample App wants to access your friend list and asking you if you would want to give your consent to do so. If you allow, Facebook will provide the relevant details to ‘Sample App’. This is how OAuth 2.0 works very briefly.

Following are the main roles in an OAuth flow.

Resource Owner: User who authorizes the third-party application to access their account.
Resource Server: Hosts the user accounts
Authorization Server: Verifies the identity of the user and issues the access token to the application.
Client Application: The application that needs to access the user's resources on resource server.

There are four grant types that OAuth 2.0 supports. They are,

Authorization Code: Used with server-side applications
Implicit: Used with mobile or web applications
Resource Owner Password Credentials: Used with trusted applications, such as those owned by the service itself
Client Credentials: Used with application API access.

I’m going to access some data from an API, but it’s another party which authorizes me to the API to access the needed data.