You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
"App Authentication" for App (without tokens). Yet another migration from long lived tokens question
Hi there! I see there have been a lot of questions in the forum on this topic, so I'll just cut to the chase.
My app is made in Meteor (NodeJS) and React. Clients of my app do not need to handle fi...
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.
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.
Scott-DB
Dropbox Staff
Dropbox StaffHi 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.
- Greg-DB
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.
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
About Discuss Dropbox Developer & API
Make connections with other developers
