Dropbox refresh token and access

Hi Everyone,

I am trying to authenticate with Dropbox. I have managed to get a access token and am able to get creation of folders and files fine. The issue is after 14400 seconds (4 hours) it doesnt seem to refresh the access token leading to it saying expired access token. It needs to work on a public link so using a custom auth wont work. If anyone has experienced this and has and advice it will be appreciated!

Thanks in advance!

You can request offline access that will give your una refresh token

I am doing that but it does not seem to refresh still. I even went into postman got a access token and refresh token put it in there and sitll nothing.

2 solutions: you can create a rest resource which will handle the oAuth process and refresh or you can make your own custom api calls.
On my app with a custom system I check with an api call if the token is still valid, if not i run an api call that exchanges the refresh token for a new access token and saves it. I hope that helps

Is that through the custom auth cause this needs to work on a public link as well.

yes custom

Hmm that wont work with a public link. Its really weird since it sees it just doesn't refresh it.

Hi Trey - did you ever get this to work? I'm having this exact same issue, I'm getting the refresh token but the refresh isn't working when the access token expires, resulting in the response below.

{
"error_summary": "expired_access_token/",
"error": {
".tag": "expired_access_token"
}
}

I'm also looking at the Google Drive API and the refresh token process for that works perfectly every time.

Thanks

Hey stu - how did you create your refresh token?
I followed the instructions given here and set up a custom auth and refresh auth workflow in retool like this:


EDIT: the API of the POST action is "https://api.dropbox.com/oauth2/token?refresh_token=my_refresh_token&grant_type=refresh_token&client_id=my_client_id&client_secret=my_client_secret"

And credentials set to

This seems to be working for me!

1 Like

Thanks Tobias, this is really helpful.

Using your approach of a Custom Auth and the docs you linked to, I was able to get the refresh auth working. I had been using the basic Retool OAuth2 option, and whilst it would deliver a refresh_token, the Dropbox oauth2/token endpoint wants different parameter values for its reauth process, as you specify in your solution above.

Interestingly, the standard OAuth2 option does allow you to share credentials between Retool users, so my next step is identify a way of making a custom auth process behave in the same way - any ideas?

Thanks again,

Stu :slightly_smiling_face:

1 Like

I did not end up getting it to work through that, what I ended up doing is having the refresh token call for a new access token when the page is refreshed and using that token to do the queries. What you could also do is send the data to a workflow and have that call the api for a new token and use that.

Hey stu, I would appreciate if you share your results if you figure that out! I wanted to switch to this eventually as well, but did not yet find the time to dig deeper.

Thanks @Trey_Anderson, fortunately I can use custom auth as I don't need it to work with a public link.

@TobiasOhlsson, I managed to get this to work by capturing the Refresh Token and storing it in a configuration variable, which persists beyond sign-out and, according to Dropbox, will never expire (we shall see!). This works across users, too. Thanks for your help.

1 Like

Hey @TobiasOhlsson and @stu, thanks for the great pointers here!

For some reason, I'm having trouble getting custom auth to work with Dropbox. Generic OAuth 2.0 works well for the initial auth workflow and I'm able to post successful requests, but when the access_token is revoked and refresh auth workflow should trigger, I'm just getting 400 responses within my app just like @stu above. Not sure if the refresh workflow doesn't trigger at all, or if it fails as the logging is minimal. Would be thankful if you can explain a few further things in your refresh setup.

  1. Assume your screenshot should be the refresh auth workflow and not the auth workflow? Or maybe I'm missing some context?
  2. Where are you getting my_refresh_token within Retool? I tried setting {{ oauth1.refreshToken }} from auth flow directly here, as well as set that to a separate variable REFRESH_TOKEN which I used here, but without results.
  3. Did you figure any way to see what's happening behind the scenes? Can't really troubleshoot as I'm not sure if anything is really happening.

Or maybe there's some context outside your screenshot that I missed completely?

Thanks,
Atte

Just realized I might be on the wrong trail above, and my actual issue is that the Dropbox API doesn't return a refreshToken unless I specify "token_access_type=offline" in the Authorization URL. However, the OAuth 2 (Generic) authentication in Retool doesn't seem to allow parameters in the URL, or at least even after adding that in the resource UI I am not receiving a refreshToken in the response.

How did everyone manage to pull the refreshToken from Dropbox to Retool? Did that require building a completely custom auth workflow? I'm thinking I might be missing some simpler solution here.

Hi atte,

You're finding the same things I did, I think it's becuase Dropbox requires a specific parameter in the reauth process that it wont accept in the initial auth process, specifically 'grant type = refresh_token'. I got around this using Tobias' custom auth flow where the reauth process can have its required parameter.

Try setting up a custom auth flow, including the token_access_type=offline you discovered above. The 'Test auth workflow' button opens a console below and, if successful, you'll see when you expand the various components in the response that the refresh token in there which can then be copied and put into a configuration variable. (if the Test auth workflow button is greyed out, go out of the resource and back in again). The refresh token is returned in the response from the initial auth call as {{http1.body.refresh_token}}

This it what my reauth screen looks like, note the configuration variables (you'll need a paid for version of retool to access these)

When the reauth process has run, you'll need to redefine the access/authorization token from the reauth response so that it can be used in the main resource header. This is the second step of the refresh auth workflow.

Thanks @stu, super helpful, makes a lot of sense!

If I can ask one more question, did you manage to set up the initial custom Auth workflow so that it would directly pull the refreshToken to Retool, and how does that look like? I made a few quick tries with no success. If not, I'll try to crack this and send my findings here later.

The refreshToken seems to be persistent, so I could just Postman or curl it and save to global configs if I was looking to just connect myself or for a shared session, but I'm looking for the opposite. I would need each user to authorize the Dropbox app for themselves, which I believe would need the initial auth workflow to pull in the refreshToken to associate it with each user's session.

Hi @atte

As I plan on just cycling the re-auth flow for a new access token, I did the one-time initial auth via a browser i.e.

https://www.dropbox.com/oauth2/authorize?client_id=my_dbx_app_client_id&response_type=code&token_access_type=offline

Copied the code given into the resource page

Step 1

Steps 2, 3, 4

Of course, once I have the refresh token stored in the config / environment variable, I no longer need this initial auth flow, Retool will trigger the reauth flow on any 4xx response code.

Thanks again, this helped me a lot. I ended up building a very similar setup, however so that the auth flow prompts for the authorization code. From that step forward, the process works fully automated and similarly as yours.

At least with reasonable amount of time I couldn't figure out a way where the Dropbox Authorization URL would automatically be called with the "offline" parameter, and the response including tokens would somehow be returned to the Auth workflow. I think this is the closest to normal OAuth 2 experience we can get for now.