No more long-lived access tokens, whats the best strategy for own account usage?

[MarciB]

Hi all, 

out situation looks like the following:

we are simply sending the file to the upload url by dropbox providing an long lived access token to OUR account. But this is not going to work starting end of september, since long lived access tokens are not supported anymore. 

To fix that, we wanted to implement the recommended PKCE flow until it dawned us, that via this way users would need to give permission for OUR account, which is not what we want. Also granting this access and then saving the refresh token as long lived token to get an access token from doesn't seem like the way to go, more of a hackjob.

Does anybody know what the recommended solution for this scenario is? Working with short-lived tokens but also not having to let the user give the permission for OUR account and not theirs. 

Greetings MarciB

[Greg-DB · Accepted solution]

While the creation of new long-lived access tokens is now deprecated, we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) without interruption. You are not required to migrate existing long-lived access tokens to short-lived access tokens. Note though that after the change you won't be able to create new long-lived access tokens.

In your case, if you did want or need to migrate (e.g., if you accidentally revoked your long-lived access token after the change), you would need to process the app authorization flow for your own account once, and store the resulting refresh token, so the app can programmatically use it to get short-lived access tokens for your own account as needed.

[MarciB]

Thanks Greg