Upload Any File to the Google Drive with OAuth 2.0 Framework

Before moving into the practical example; if you don’t have any idea about OAuth framework, Read this.

In this example; we’ll be using Node.js, JavaScript, HTML, Bootstrap, Ajax, and JQuery to develop a simple application with 2 interfaces.

1. Login Interface to Authenticate the user with Google OAuth
2. Interface to Browse any file and Upload it to the Drive

Source: https://developers.google.com/identity/protocols/OAuth2

Given diagram is a complete overview of how this application works with the Google Servers. Each part of the image will be discussed later in this article.

Before moving onto the implementation, Let's see how this application works.

To start of this, main requirement is to have a Google Account. If you don’t have any, it is required to create it right now.

Setting up the Google Console

Once you have a Google Account, go to https://console.developers.google.com and follow the steps given below.

When you use the Google Console for the very first time, it may be different from the image given above. Click create a new project dropdown menu.

Next click on the New Project window and create a new project for the application giving a name for the identification.

If the project is created successfully, you will receive a notification as shown above. Next, click on the Enable Apps and Services button on the Home page.

Then search for Google Drive as we are going to use Google Drive API in our OAuth application. If you are using different Google Service, search for that in the search box.

Click on Google Drive and Enable it.

After enabling it, you’ll be redirected back to the home page. Click on the credentials tab and set a new credential for the project.

From the dropdown, select OAuth Client ID as we are going to use OAuth Client ID and Secret in our application.

In the popping up window, you have to set a consent screen. For that, click on the Configure consent screen button.

After setting the consent screen, you need to select web application as the type and set the URL of the application. 

In my case, I’m deploying my application using a Node Server which runs on the port 3000. For the redirect URL, you need to provide a page wherein any case if application didn’t find your URL, it will be redirected to that page. Simply, your /error page.

Once you provide the necessary information, your client id and the secret are created for the application. This is used to consume the service of an OAuth Authorization Server and an OAuth Resource Server.

Message Flow Explanation

In our application, we have 2 main files which hold the logic of the application. i.e. index.js and upload.js.

The main folder structure is shown below. All the resource files including .html, .css and .js files are stored in the public folder. App.js contains the code to up the node server.

Index.js file authenticates and authorizes with the Authorization Server and grant code (Authorization Code) is generated.

Upload.js file uses that code and requests the access token from the Authorization Server. Using that, resources are obtained from the Resource Server. In here, Google act as both the Resource Server and Authorization Server.

1. The application (OAuth Assignment SSD) request the authentication to access to the information of the Google Account.
2. User Agent/ Resource Owner sends the authentication and grant authorization request to the Authorization Server (Google). Authorization Server contains to subparts Token Endpoint and the Authorize Endpoint.
3. Authorization Server responds with the Authorization Code
4. User Agent sends the authorization code to the application and application receives an authorization grant after the consent.
5. The application presents the authentication of its own identity and authorization grant to the Authorization Server to request an Access Token.
6. Authorization Server checks for the validity of the application’s authentication and authorization and grant an access token.
7. The application uses the token and requests for resources used in the application from the Resource Server.
8. Resource Server checks the validity of the access token and grants the resources to the application.

Complete Source Code of this project can be found out in the GitHub Repository. Click here to download it.

Important: It needs to up the Node server. For that, go to the folder which contains the files and open a command prompt.

Then type node app.js to run the node server.

Deployment Guide is given in the ReadMe file in the repository.

After running the application, this is how it looks like.

After obtaining the above interface from the URL http://localhost:3000/index.html, Click on the Login to Google button.

It is important to mention that if you have already logged into your Google account, you are not getting the above interface.

As already cookies contain the authenticated information. So it is better to use incognito mode in your browser or logout from the Google account.

Now our application, asks to provide the email address of the Google account of yours. After providing the email address, you need to provide the password in the below interface.

If both the email and password matches, you’ll be authenticated via the Authentication Server.

As we have not verified our application in the Google Console, you may get the below warning message. But neglect it at this moment and proceed ahead.

Once you proceed ahead, Google asks whether to allow the permissions derived in the application that we are using.

As our application only uploads a file to the Google Drive, we ask for see, edit and delete the file permission from the user.

Once an access token is validated by the Resource Server, those resources are granted for the application and user will be redirected to the redirect URL. In our case, it is upload.html; http://localhost:3000/upload.html

User can select any file and click the upload button to upload it to the Google Drive. Once it is uploaded successfully, the message will be displayed at the bottom.

If we right-click on the page and go to the inspect element, you can see the URL of the file uploaded to the Google Drive as shown below.

Finally, you can check whether the file is uploaded into the Google Drive.

Now let’s go deep down to see how this application works with the coding.

Step 1 - Obtaining the Authorization Code

To get the Authorization Code, we need to send a GET request to the Google Authorization Server. For that, you have to send, 4 parameters as shown below.

Parameter Name	Value
response_type	code
client_id	349805278143-c2vi2ruhvv8032fq9558sr111ohbn6pp.apps.googleusercontent.com
redirect_uri	http://localhost:3000/upload.html
scope	https://www.googleapis.com/auth/drive

A separate method is created to request the authorization code from the Authorization Server. In the above request, redirect URL, response type, client id, and scope need to be provided.

The exact URL endpoint used here is specified by the service itself. But the parameter names defined will be same.

Important: If the application is registered and the redirection URL is not provided, this application won't work.

Authorization Grant Parameter List

response_type: It is set to code as we are using the grant type as the authorization code which we expect in the response.

client_id: Unique identifier created at the registration of the application.

redirect_uri: URL defined to redirect the user after the successful authorization. In this application, we are redirecting the user to the upload interface.

scope: In scope, we define the access levels of the application. In this application, we are only using GDrive and we have defined it in the scope. If more than one scope is used, we have to define it here.

Step 2 - Obtaining the Access Token

Parameter Name	Value
grant_type	authorization_code
client_id	349805278143-c2vi2ruhvv8032fq9558sr111ohbn6pp.apps.googleusercontent.com
redirect_uri	http://localhost:3000/upload.html
code	4/qwGuUbToxrClP6H3XKI4CdjKLhlZxk8YXb8o6z7kjPmOew-AZC14uYxQkbkNcyjbtZ07ybJCMBsD6z1-w7VXqCo

Before accessing the private information using Google API, OAuth SSD application need to obtain an access token which grants the required permissions. 

Using this token, we can access multiple Google APIs. But, as we have defined the scope in Step 1 only to access Google Drive, we don’t have the permission to access any other Google APIs. 

In this application, browser redirects to Google with the relevant scope and request a token for the application.

We are creating a POST request with the relevant parameters to send to the Google Authorization Server. When the server verifies the identity, a unique access token is issued. Then the access token is saved into the local storage using JavaScript function.

Step 3 - Uploading the File

After obtaining the access token from the Authorization Server, we send another request to the Resource Server with the access token to grant permission to upload a file to the Google Drive.

In above, we create a method to get the file from the user and upload it to the Server. Once the file is uploaded successfully, success message is displayed. Depending on the size of the file uploading, it may take sometime.

References

https://www.oauth.com/oauth2-servers/accessing-data/obtaining-an-access-token/

http://www.securityinternal.com/2017/04/retrieving-user-resources-from-facebook.html

https://developers.google.com/identity/protocols/OAuth2

https://tools.ietf.org/html/rfc6749

What is OAuth and how does it work exactly?

OAuth: open authorization protocol which allows third parties to provide limited access to protected resources without having to transfer a username and password.

For example, a user who wants to give the social network service with access to the contacts of his mail does not have to inform the social network of his email password. Instead, the user is authorized in the mail service, which provides the social network service with access to the address book.

A bit of history

OAuth 1.0

OAuth started in November 2006 when Blaine Cook was developing an OpenID implementation for Twitter. 

Together with Chris Messina, Blaine was looking for a way to use OpenID to access the Twitter API without providing a password service. 

Collaborating with one of the OpenID developers, David Recordon, Cook analyzed OpenID functionality and authorization protocols such as Yahoo! BBAuth, Google AuthSub, Flickr Auth. It was concluded that a new open contract is needed. 

So, in April 2007, a group of developers was formed who were engaged in its creation. The group was attended by employees of AOL and Google. The final version of the OAuth 1.0 the protocol was presented on December 4, 2007, and in 2008 work began on standardizing the protocol.

OAuth 2.0

In 2010, work began on a new version of the OAuth 2.0 protocol. The main goal of the latest version is to simplify the development of client applications.

The difference between OAuth and OpenID

The opinion that OAuth is an extension of the OpenID protocol is erroneous. 

Although OpenID and OAuth have much in common, OAuth is a standalone protocol and has nothing to do with OpenID.

OAuth allows you to grant rights to use a resource. The availability of reasons is determined by a token, which can be the same for different users, or one user can have different symbols at different times. Rights are granted in exchange for the provision of a logo.

OpenID is an authentication tool. With its help, you can make sure that the user is exactly who he claims to be.

OAuth Scheme

For example, a user wants to print his photos, which are uploaded to pixabay.com using the google drive service

• The client using the HTTPS protocol sends a request to the service with the contents of the client identifier, timestamp, callback address, at which it will be necessary to return the token, type of digital signature and, directly, the numeric name itself

• The server confirms the request and responds to the client with an access token and part of the shared secret.

• The client transfers the token to the owner of the resources and redirects the token to the server for authorization.

• The server receives a token and requests a username and password. If authentication is successful, then asks for confirmation of access to resources, after which the user is redirected by the server to the client

• The client passes the token to the server using the TLS protocol and requests access to resources

• The server confirms the request and responds to a client with a new access token.

• The client uses a new token to access the server for resources

• The server confirms and provides resources.