"App Authentication" for App (without tokens). Yet another migration from long lived tokens question

@lalomores Just like with long-lived access tokens, the user needs to manually authorize the app once to get the refresh token, which can then be stored and re-used without further manual user interaction. In that example, you can see where the SDK returns the refresh token, which is then set on the client, on this line: https://github.com/dropbox/dropbox-sdk-js/blob/main/examples/javascript/simple-backend/code_flow_example.js#L38 . You can store and programmatically re-use that 'token.result.refresh_token' value similar to how you would store and programmatically re-use a long-lived access token.

The refresh token is used to programmatically retrieve new short-lived access tokens whenever needed, without the user necessarily present. Those new short-lived access tokens that get retrieved automatically are what are used to then make actual API calls, such as filesListFolder (or usersGetCurrentAccount, as in the example).

Anyway, while Dropbox and the Dropbox API aren't really designed to be used as a CDN, we do recommend using the official SDK(s) whenever possible for accessing the Dropbox API. And using the app folder access type whenever that works for the use case is also a best practice.

All comments

@lalomores wrote:
... Files are not client related, only related to my Dropbox App and corresponding Dropbox app folder.
...

Hi @lalomores,

Hmm... 🤔 Ok, is the application folder for anyone particular application (including your) just a single thing or is it something specific to every one account, which the same application gets link to?! 🤫

@lalomores wrote:
...
Checking the Authentication Types the most obvious candidate to replace my long lived token, seems to be "App Authentication": "This type only uses the app's own app key and secret, and doesn't identify a specific user or team". That's perfect....

In context of findings achieved above (I hope), are you keep thinking "App Authentication" is perfect for your case? 🧐

You have correctly noted that "doesn't identify a specific user or team". That means the Application folder will left out untouchable, because it's an account specific thing, NOT application specific (or not only, at lest)! Application authentication is usable in case of processing resources unassigned to any particular account. The example, you provided above, describes process of assigning application to account. At the beginning only application has to be authenticated because it's still not linked to an account and that's why can't do anything account related. Next user confirmation, the example rely on token from that moment on, not to Application authentication only! That's why access to user related data gets possible.

Application authentication is convenient for use in cases like performing actions on public data like shared links, for example. Like a person receiving a link can see it and so on, your application can do the same without user authentication. Accessing link doesn't need user authentication in context of account. If there is any kind of additional authentication set by the link issuer, it can be applied too in borders of Application authentication, like human will do.

Again, inapplicable when any kind of account access is need, even when seems negligible! 😉

Hope this clarifies matter.

Hi @Здравко, thanks for the quick answer!

Your answer makes me think there might be some fundamental missunderstanding/missinterpretation of what an "App folder" is (from my side).

Now, my intentions are to obtain an equivalent effect to that of the long lived token. In my app, that was:

1. My app silently synchronized whatever the Dropbox App Folder had. By synchronize I mean it kept a Mongo table with data about the files names, paths, extensions and created/obtained shared links to each file in the app folder. It did this regularly (say each 15')

2. End users had no idea Dropbox was involved in anyway

3. End users never had to sign in into dropbox. They in fact don't need dropbox accounts to use this app.

4. Whenever an end user searched for a product that had related files (as per their names), they saw the product images or documents (by using the shared links the synchronization made sure exists)

The dropbox App Folder was used to:

- Upload product images

- Upload product documents

This would be done either by the owner of the dropbox account (same that created the app in the app console), or by another Dropbox account which the app folder (or a subfolder) has been shared with.

I hope this better clarifies my context and intentions.

Long lived tokens allowed me to achieve this transparency to the end users.

Is there a way to achieve the same now with the new approach Dropbox is taking?

Scott-DB

Hi @lalomores,

It sounds like your application needs to have indefinite access to only your account and no other account. For that, you should generate a refresh token and use that to create an access token as needed. For more information getting a refresh token, see the /oauth2/token documentation. Refresh tokens can be used indefinitely without manual interaction like long lived tokens.

Also, with app auth, you may only access content which is publicly available (since there is no user or team auth associated with it). So you would need to make a shared link for your folder in order for an app with app auth to access it, otherwise you will need to use user auth with a refresh token.

Hope this helps!

Thank you very much @serickson

Does the dropbox-sdk-js have a way to obtain the refresh token programmatically without prompting the user? As per your feedback I guess it does, but I'm just not hitting that nail it seems.

From the aforementioned example:

const config = {
  fetch,
  clientId: 'jg8wc1hfkvel6ql',
  clientSecret: 'f0i5w4e6mlbbme5',
};

const { Dropbox } = require('dropbox'); // eslint-disable-line import/no-unresolved

const dbx = new Dropbox(config);

That way I initialize Dropbox in the server using clientId and clientSecret.

What's next in order to enable this.dbx.filesListFolder ?

I'm a bit tangled up looking and playing with the APIs at https://github.com/dropbox/dropbox-sdk-js/blob/main/src/auth.js

Also, given the context I've mentioned and my app objectives (basically, to use Dropbox as a kind CDN for my app's images), would you advise a better way to use the Dropbox SDK and App folder to achieve my goals?

Thanks a lot.

Oh, I see. I finally understand. Thank you Greg and everybody for your patience.

So, in short, what I want is not possible:

1. It is not enough with the client Id and client Secret to programmatically obtain a refresh token.

2. I can't avoid having to go through at least one oauth flow in the client to retrieve a refresh token.

If I want to entirely hide the Dropbox oauth flow from my users, I need to do it in a kind-of-hacky way: run it myself either in my app or in an example code as the aforementioned, capturing the generated refresh-token in the server and then using it as a constant for my app's initial setup. Is that right?

I think my confusion came from the fact that it didn't quite feel like I was authorizing anything when I generated a long-lived token in the app panel. The same way it didn't feel like I was authorizing the client id and secret when I created the app in the console. It felt more like configuring/setting up.

So, to give closure to this matter and if you would be so kind to answer me one more time: Would you say obtaining a refresh token, capturing it and using it as a long-lived token is something that goes against Dropbox's intended/best practices?

Otherwise, if Dropbox is actually expecting refresh tokens to be used as long-lived ones, an idea that comes to mind is maybe replacing the "Generate access token" with a "Generate refresh token" in the app console, as this section feels more like configuration than temporary data. And maybe leaving the "Generate access token" (and maybe calling it: Generate short-lived access token) in the API explorer, so it is clear it can be used for a little while just for testing purpose.

Thanks a lot for your insights and help.

Best regards

Yes, that's correct. The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. While it is technically possible to always connect to just one account for all users, we do not officially support this, for various technical and security reasons.

I'll also pass this along as a request for a "Generate refresh token" option, as well as to clarify the token lifetime in the API v2 Explorer, but I can't promise if or when that might be implemented.

Thanks a lot.

Black Jack

+1 for "Generate refresh token"

I have spent hours trying to get the API working. It worked great before the tokens started expiring every 4 hours. I have read everything I can find about this, but I can't piece it together. I have an app that need to access a dedicated Dropbox folder. I don't care who is using the app, and I don't want the users to need to authenticate. It worked well with the long term token I generated in the app console before that option was removed.

It seems like now I have to figure out how to build a separate app just to authorize and create the token. I would love to be able to generate a token from the app console similar to how we could before. This would save me many, many hours of work.

Hi @dwissing,

Take a look on https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Issue-in-generating-access-token/td-p/592667 how you would be able do the same in regular terminal. 😉

Hope this helps.

So this shows how to refresh a token manually in terminal. My app is Vue.js. Current code is: import { Dropbox } from 'dropbox'

import { Dropbox } from 'dropbox'
import axios from 'axios'
async function get_thumbnail() {
  const dropbox_token =
    'sl.**CODE**'
  const options = {
    format: 'jpeg',
    mode: 'strict',
    path: found_file_path.value,
    size: 'w64h64'
  }
  var dbx = new Dropbox({
    accessToken: dropbox_token
  })
  try {
    const response = await dbx.filesGetThumbnail(options)
    return response
  } catch (error) {
    console.log(error)
  }
}

I can use the info you provided in a terminal to get a new access token, but how do I do it automatically?

</code></pre><P>&nbsp;</P><P>&nbsp;</P><pre class="lia-code-sample language-javascript"><code>

@dwissing wrote:
...
I can use the info you provided in a terminal to get a new access token, but how do I do it automatically?
...

🙂 No, no, no... Seems my forwarding was too brief and no very clear.

On the page, I referred to above, entire work flow is described, not only initial authentication! The last part there, as you noticed, is refresh description. Since you are using Dropbox SDK, where refresh process is implemented internally, you don't need to do it by hand. 😁 In such a way you would do some job of SDK by hand.

The only thing you need to do is initialization of Dropbox client object using refresh token, instead of access token. That's it. In addition it's NOT good idea every time when need to perform particular operation, new object sets up (like you are doing now). This leads to efficiency lost. Better, set one client object at the beginning (with global view or so), keep it, and use it till the end.

Take a look here how you can initialize a client object using refresh token. 😉

Hope it's a bit more clear now.

@dwissing Здравко is correct, and offered helpful guidance, so please refer to that. Also, note that refresh tokens don't expire, so you can store and re-use them repeatedly.

@Greg-DB wrote:
... , so you can store and re-use them repeatedly.

@Greg-DB, better let @dwissing focus on the particular setup. No storage or reusage is need in particular case. The refresh token is available as a constant and can be used as a replacement for 'token.result.refresh_token', in particular.

Thank you.

I tried just replacing the access token with the refresh token in the dbx - new Dropbox() line, but that did not work.

The example you pointed to uses the key and secret in this command, along with "fetch". I am not familiar with fetch, but I get the following error:

TypeError: Failed to execute 'fetch' on 'Window': Illegal invocation
at Dropbox2.fetch (<anonymous>:1:876)
at dropbox.js:108:22

import { Dropbox } from 'dropbox'
import axios from 'axios'
const config = {
  fetch,
  clientId: 'app_key',
  clientSecret: 'app_secret'
}
var dbx = new Dropbox(config)

async function get_thumbnail() {
  const options = {
    format: 'jpeg',
    mode: 'strict',
    path: found_file_path.value,
    size: 'w64h64'
  }

  try {
    const response = await dbx.filesGetThumbnail(options)
    return response
  } catch (error) {
    console.log(error)
  }
}

@Здравкоwrote:
...
The only thing you need to do is initialization of Dropbox client object using refresh token, instead of access token.
...

@dwissing wrote:
...
I tried just replacing the access token with the refresh token in the dbx - new Dropbox() line, but that did not work.
...

Of course, what did you expect??? 🤔 Did you expect different way of initialization and replacement to be the same? Does referred example use refresh token just as an access token replacement? (or not exactly) 🤷

Where you are getting this 'fetch' from? 🧐 (take a look on the example once again) 😉

Where you are setting your refresh token actually??? 🤦 (focus on the enlightened line in the example, once again)

Ensharp your attention little bit! 🙂

The example you linked to above has this setup:

const fetch = require('node-fetch');
const app = require('express')();

const hostname = 'localhost';
const port = 3000;

const config = {
  fetch,
  clientId: 'jg8wc1hfkvel6ql',
  clientSecret: 'f0i5w4e6mlbbme5',
};

const { Dropbox } = require('dropbox'); // eslint-disable-line import/no-unresolved

const dbx = new Dropbox(config);

Instead of using an access token in the "new Dropbox()" command, they are using the above config including "fetch". I don't really understand how this works, or where I can put the refresh token in order to use it to create a new Dropbox object.

@dwissing wrote:
... I don't really understand how this works, or where I can put the refresh token in order to use it to create a new Dropbox object.

Ok, I'm putting the example with enlightened line here again. Can you explain what exactly this line is doing (exactly this, no any other)? What will change if you replace the argument there to your refresh token literal? 🤔

Don't go fast! Relax little bit (as much as need). When you get ready, take a look on the line. What are you seeing there, what this line does actually? What if you put this line at the beginning? (next client object creation)

Then i used postman to get a short-lived access token using a POST call to the url https://api.dropboxapi.com/oauth2/token using the requered paramethers (Refresh token included)

Thank you. I think I have it now.

I was thinking that you needed to already have the authenticated token before creating the new Dropbox object.

I didn't realize you could create an un-authenticated dbx object, and the call a method on it to authenticate.

I appreciate your patience and help. 🙂

maxcastrovidal

Hello,

It seems that it is not true that the RefreshToken have permanent duration.

I got a Refresh Token by calling from my browser the url https://www.dropbox.com/oauth2/authorize?client_id=xxxxxxx&response_type=code

After the short-lived access token finishes his useful life (4 hours) i ran again the same Postman Call (with the same parameters) to get a new short-lived access token, but now the response is

{

"error": "invalid_grant",

"error_description": "code doesn't exist or has expired"

}

Can you helpme please to solve tis issue?... i spent many hour trying to automate mi process but still i can't.

Hi @maxcastrovidal,

Don't have any doubts - refresh token doesn't expire by itself.

@maxcastrovidal wrote:
...
After the short-lived access token finishes his useful life (4 hours) i ran again the same Postman Call (with the same parameters) to get a new short-lived access token, but now the response is
{
"error": "invalid_grant",
"error_description": "code doesn't exist or has expired"
}
...

👍Yes you are on the right track, you need to refresh (to create anew) your short-lived access token from the refresh token you already have. But... 🤔 Why are you using already expired code used formerly to get to the refresh token???! Once again, you already have this refresh token! Even more, code used to get this token is "single shoot" (i.e. once used, you can't use it any more and don't need actually).

Don't try to "refresh" refresh token itself, if you are trying this! You need to refresh the access token! Access token refreshing doesn't need "code", but a refresh token instead. 😉 Check what granting type you have selected (may be a copy/paste error - grant types for refresh token and access token are different).

Hope this helps.

By the way, using:

@maxcastrovidal wrote:
...
I got a Refresh Token by calling from my browser the url https://www.dropbox.com/oauth2/authorize?client_id=xxxxxxx&response_type=code
...

... you will never get any refresh token!!! You have to specify explicitly offline access! Something like:

https://www.dropbox.com/oauth2/authorize?token_access_type=offline&response_type=code&client_id=<App key>

In your situation whatever you are counting as a refresh token, it's not! 🤷