Articles in this section

Verification

In our last article we walked through the setup of a web application that uploads text files. We utilized our open-source tool called the Authenticator (https://github.com/Kloudless/authenticator.js) to help with authentication. That article focused mainly on the client-side setup of the web application and how to pass the information to your web server. In this article, we’ll be taking a closer look at authentication processes and best practices on the server-side of our web application.

Our web application is now set up to submit a form with all the information needed from the end-user to create and upload a file to their Google Drive account. However, before we do so it is important to verify that our authentication information is coming from the correct application. By doing so, we prevent a Confused Deputy attack, which is when an attacker obtains access tokens through a compromised client or other mechanism and uses this to impersonate the end-user to gain access to the resource.

Our form passes several bits of data to the server; `fileName`, `fileBody`, `access_token`, and `account_id`. `fileName` and `fileBody` are used to create the .txt file. Before we upload that to Google Drive, we need to validate the token by confirming it was issued from your Kloudless application. We can do that by ensuring the token was created in association with your application’s client ID. We can ensure that the server-side code is aware of its Kloudless client ID. We can also find out which Kloudless application granted the access token by performing a GET request to Kloudless with the Bearer token included in the header (https://developers.kloudless.com/docs/v1/authentication#header-verify-the-token).

To confirm the token is from correct application, we can compare the response data with information we supply about the application. If that data matches up, then we can continue the action as legitimate access. If not, we can not only deny the action, but also revoke the suspect token.

If you have a valid token the request from the client, a 200 status code will be returned with a JSON body containing the client ID the token was granted to, the account ID that the token will access, and the scope of the access token.

With that information, you can compare the server-side accessible client ID to the client ID that was returned from the GET request. This is the minimum amount of verification you should include in your application. If possible, you can also verify the Account ID in the same manner.

If the access token was not granted by your application, you can stop the request. Additionally, it is a good idea to revoke tokens that get a 200 status code response but do not match your client ID.

With the token now verified, you can make an API call to Kloudless to upload the file to the identified location in the service. In our case, the text uploading application creates a .txt file that is uploaded to the root folder of a Google Drive account. The app uses the Kloudless Node SDK to craft that call. You can see the full code for that app here!