Dropbox not sending refresh_token using new OAuth2 flow

Vicne

Hi,

 

(Sorry I first posted this as a reply to this "solved" topic, which was a bad idea because it's mostly unrelated)

 

I'm developing a "native" app (called Ginj), and started Dropbox integration a few weeks ago.

I first used Dropbox's Java API for authorization, using PKCE and "copy/paste" from browser to app, and it seemed to work pretty well but now it seems I'm forced to re-authorize regularly.

After checking the received tokens, they are now indeed short-lived "sl-..." tokens, so I decided to call the REST OAuth API myself to see if I could implement the updated flow, and also get rid of the copy/paste step.

I think I'm nearly done, but when exchanging the received code for tokens, the response I'm getting contains an "access_token", but no "refresh_token" and no "expires_in". 

Now the access token seems to be "long lived" again, but I'm reading non-expiring tokens are getting deprecated, so I'd rather switch to the refresh logic while I'm at it...

How can I get a refresh_token ?

 

KR, 

Vicne

Greg-DB

We recommend just using the official SDKs whenever possible, as they'll do most of the work for you, but you can certainly use the HTTPS endpoints directly if you'd like.

 

You can find information on this in the authorization documentation, as well as the new OAuth Guide.

 

Most apps currently default to long-lived access tokens, but if you want to start using short-lived access tokens, you should set the 'token_access_type' parameter on your /oauth2/authorize URL. You can find information on using that in the /oauth2/authorize documentation. Specifically, to get short-lived tokens with a refresh token, you should set it to "offline".