Issues with server side process authentication

[bt619]

I have a server side process that generates documents and then needs to send them to a folder in Dropbox. There is an app created to with access to the folder. I was able to generate a token for the app and initial testing went well. Based on the documentation the token should last forever, but it appears to be a token that has now expired. The API calls to generate a new token with any of the Code auth flows are failing and it looks like it assumes there is a user somewhere. There is no actual user. There is just a server creating documents and sending them to the folder with cURL. I could use a little guidance on this.

[Greg-DB]

Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is now issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.

Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation. There's a basic outline of processing this flow in this blog post which may serve as a useful example.

[bt619]

Greg, this was not very helpful. Per the documentation there is no redirect url and the blog post you referenced clearly states "After the user has authorized your app". There is no user, there is an app. I expect support to be a little better than links to the documentation I have already read prior to asking for assistance.

[Greg-DB]

An OAuth 2 redirect URI is a URI that the developer wants the user sent back to after authorizing the app, however this is optional. You do not need to use a redirect URI if you can't or don't want to. When you don't use a redirect URI, the authorization code is instead present in the UI directly to be copied/pasted back into the app manually.

Also, both when using the old long-lived access tokens as well as now using short-lived access tokens and optional refresh tokens, there is always some user account involved. If the integration is just for your own use and you won't be releasing your integration to other users, the user account would just be your own account, and you would be the one to perform the authorization.

For your own account, you can perform the authorization using the "Generate" button on the app's info page, or use the actual OAuth app authorization flow.

If you need long-term access though (that is, for long-term access without the user present after the initial authorization), you'll need to request and use a refresh token as described. Note that it's only possible to get a refresh token using the OAuth app authorization flow; the "Generate" button does not offer the ability to get a refresh token.

[bt619]

Can I get a refresh token with the expired short lived token I have already?

[Greg-DB]

No, it is not possible to get a refresh token by using an expired short-lived access token. You can only get a refresh token by processing the OAuth app authorization flow and requesting "offline" access. This only needs to be done once per account though, as the refresh token itself does not expire and can be re-used repeatedly.