Kloudless FAQs

If you have built a quick test application on the Kloudless platform, chances are that you did so using default OAuth keys Kloudless provides to facilitate testing the API. If you have begun building your Kloudless integration, it is a great time to switch over to an OAuth flow that utilizes your own OAuth keys. This provides several benefits; it allows you to manage your own tokens, you get a better branding experience, and finally youwon'tbe sharing rate limits/quotas the Kloudless default keys are subject to. So lets dive in!

In this example, well walk through moving an existing Google Drive app from Default Kloudless keys to keys supplied by Google. To start off, navigate to the OAuth Credentials page in the developer portal for your app. You can find this page under Security -> Credentials in the developer portal. Be sure to select the correct app from the dropdown menu in the top left corner of the page. You should see a list of cloud storage services that looks something like this:

Kloudless Credentials page

In our case, we are looking for the listing for Google Drive. When you find that entry, you will see that Google Drive is by default set to the Default Kloudless keys. If you have existing accounts connected to the Default key, you will see a message denoting the number of accounts using that key, and an option to delete these accounts bordered in red, with some additional information.

In our case, we do not need these accounts to continue to have access, and would like to have them re-authenticate through our app in the future. In this case I will check the box to have the existing accounts deleted. Please note, this deletion does not affect the contents of your account or delete the account; but they do remove access to the account the keys are associated with.

Once you click Save, the first thing youll see is several new fields with instructions and helpful information specific to OAuth tokens and Google.

Keep this browser tab open, well be coming back to it in a bit. Were now ready to head over to the Google Developers Console ! If you havent yet, create a new Google project. This is where youll manage apps and services that request access to your users Google accounts, and generate a Client ID/Consumer Key and our Client Secret/Consumer Secret. Once that is done, there are a few steps to follow to get the information from the Google project. It should look something like the image below once you have created the project, with your project name in place of kloudless test auth.

Our next step is to create the credentials needed for the Kloudless app. Click on the Credentials tab to look at our options for creating credentials. In this case, were creating an OAuth Client ID, so select that option and then select the correct application type. In this case, I selected Web application. All right! We now have a Client ID/Consumer Key and our Client Secret/Consumer Secret.

Weve got something else to editin the Google Developers Console; the callback URL or Redirect URI. Please refer back to the Kloudless Credentials page and grab the link supplied there. Copy and paste that into the field under authorized redirect URIs, and click save.

Please keep in mind that the Client secret is just that - a SECRET. Be mindful of where you save it, and do not leave it exposed in your documentation. Head back to the . Enter the Client ID and Client secret into their respective fields, and save the app.

Thats it! You have successfully moved your app from using the default Kloudless OAuth keys to your own OAuth keys.

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, well 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 applications 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 ).

axios.get('https://api.kloudless.com/v1/oauth/token', {

headers: {

'Authorization': 'Bearer ' + access_token

}

})

.then(function(response) {

//******** Successful API response handler

})

.catch(function(error) {

//******** Unsuccessful API response handler

console.log(error);

})

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.

const test_client_id = response.data.client_id;

if (kloudless_client_id === test_client_id) {

//******** Handle successful token verification

} else {

//******** Handle unverified tokens

}

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.

axios.delete('https://api.kloudless.com/v1/oauth/token', {

params: {

'token': access_token

}

})

.then(function(response) {

console.log('invalid grant token, revoked.');

res.render('deleted');

})

.catch(function(error) {

console.log(error);

});

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!

In this article, well use Kloudlesss Authenticator JS, an open-source plugin that prompts the user to grant access to a given cloud service, and how to handle that operation. We will look at the setup of a basic web server, and how to use the Authenticator to setup a client-side form with all the data needed to submit to a server-side API call. Authenticator JS has documentation that we will reference through the article. You can find them here.

Here is a form with all the fields needed to create a basic .txt file, which will eventually end up stored in the Google Drive account that the user has access to and granted permission to utilize.

form.html

<form action="/post" method="post">

<div>

<input type="text" name="fileName" placeholder="File Name">

</div>

<div>

<textarea name="fileBody" rows="7">File text here.</textarea>

</div>

<div>

<button type="submit">Create and upload file</button>

</div>

<input type="hidden" name="access_token" id="access_token" value="">

<input type="hidden" name="account_id" id="account_id" value="">

</form>

Our web server is Node + Express based, and will use the submitted form data to create a file, verify the authentication token, construct an API call, and run some cleanup once the action is complete. If you look at the code above, there are two inputs with the type=hidden that do not yet contain values. These values, account_id and access_token need to be supplied to us in order to access the storage service. Here is where the Authenticator JS plugin comes in.

First we need to obtain the correct values. To do so well need to embed the Authenticator in the client-side page using this script tag, which is documented in the Authenticators README.

form.html

<script type="text/javascript" src="https://static-cdn.kloudless.com/p/platform/sdk/kloudless.authenticator.js"></script>

This exposes a global `Kloudless` object. This contains `Kloudless.authenticator` method, which is what well use to trigger an authentication pop-up for the end-user.

authenticator.js

Kloudless.authenticator(element, params, callback)

Before that can happen, we need to setup some logic to handle the end-users input. `element` is the triggering action, for this example Ive used jQuery to set the triggering element. We also need to pass the configuration to the `Kloudless.authenticator` method to suit our application needs. They are required parameters that the end-user does not need to be aware of, but that do need to be passed in to the authentication. At the minimum, you must pass a client ID to identify the Kloudless app. In our case, we only need to authenticate one service, Google Drive, so we will also be setting `scope` in our configuration. The config will look like this:

const config = {

'client_id': '[INSERT YOUR CLIENT ID HERE]',

'scope': 'gdrive',

};

This gives a great setup for the authenticator.js. Lets see how what we have so far could be laid out:

$(document).ready(() => {

const config = {

'client_id': '[INSERT YOUR CLIENT ID HERE]',

'scope': 'gdrive',

};

let auth = Kloudless.authenticator($press, config, callback);

});

The next pieces we need to include will be setting up some more jQuery use to set our received data to the correct inputs in our form, and setting a callback function that will determine what we do with the response data. The jQuery setup is pretty quick, something that defines some needed variables

const $press = $('#submitAuth');

const $account_id = $('#account_id');

const $access_token = $('#access_token');

const $uploadButton = $('#uploadButton');

Now for the callback function setup. Well need to handle errors, as well as what to do with our successful data. Using the variables we just setup, we can reset the input values with the returned information

let callback = function (result) {

if (result.error) {

console.log('An error occurred:', result.error);

return;

}

$account_id.val(result.account.id);

$access_token.val(result.access_token);

$uploadButton.prop('disabled',false);

};

Our authenticator.js should now looks something like this:

$(document).ready(() => {

const config = {

'client_id': '[INSERT YOUR CLIENT ID HERE]',

'scope': 'gdrive',

};

const $press = $('#submitAuth');

const $account_id = $('#account_id');

const $access_token = $('#access_token');

const $uploadButton = $('#uploadButton');

let callback = function (result) {

if (result.error) {

console.log('An error occurred:', result.error);

return;

}

$account_id.val(result.account.id);

$access_token.val(result.access_token);

$uploadButton.prop('disabled',false);

};

let auth = Kloudless.authenticator($press, config, callback);});

With that, we now have all the data in need to send to our server-side code to make and API call. Our next article will cover some of the server-side setup needed to make the API call, as well as cover some important security setup needed to ensure your app is less vulnerable to certain kinds of malicious attacks aimed at OAuth.

In prior articles, weve covered how to set up a Kloudless account to use custom OAuth keys for users. However, access to the organizations data and services may not be best served by granting full access to all users. There may be too much data, or sensitive data that can be made more secure by limiting access.

Typically the users setting those access permissions (administrators) have additional tools and access at their fingertips for testing and setting up user accounts. However, that additional level of access also requires a more involved authorization. Kloudless can be configured to provide administrator account access using OAuth for many upstream services. Our documentation can provide additional information on which services are supported.

In order to setup credentials to authenticate administrators, there are additional pieces of information that need to be setup or created. You can find that setup on the Kloudless Credentials page under the Use Your [SERVICE NAME] Keys menu. At the bottom of the services entry, there is a link that looks like this:

[email protected]

This will then allow you to add administrator credentials to your Kloudless application to allow administrator users to connect and utilize the expanded set of tools available to them. Each upstream service accomplishes this slightly differently, and the Credentials page contains helpful information for properly configuring the application. If you are attempting to setup these credentials and run into any problems, please reach out to us at and we will help to get your admins online and connected!