End of long-lived tokens: integrations break unless they adopt refresh tokens
September 2021
On 30 September 2021 Dropbox stopped issuing the never-expiring access tokens many integrations relied on, switching to short-lived tokens plus refresh tokens — backups, scripts, and self-hosted tools that hard-coded a static token broke unless rewritten.
What happened
Historically a Dropbox developer could generate a single long-lived access token that never expired and paste it into a script, a backup tool, or a self-hosted application. That model ended: on 30 September 2021 Dropbox retired the creation of long-lived access tokens, so every newly generated token is short-lived and expires after a few hours.
The replacement requires apps to request 'offline' access during OAuth, receive a long-lived refresh token, and use it to mint fresh short-lived access tokens as needed. This is more secure, but it is also more work, and it broke a common simple pattern. Numerous open-source projects and integrations — backup utilities, media servers, Flysystem adapters, and others — filed issues and shipped fixes because their long-lived-token setup could no longer be reproduced for new users. Dropbox said it did not plan to immediately disable already-issued long-lived tokens, but no new ones could be created, so any tool whose setup instructions told users to generate a token was effectively broken for new installs.
Impact
For automation, backup, and self-hosted use cases, this was the most disruptive of Dropbox's auth changes, because those tools were precisely the ones that had leaned on a static token and the least likely to have a full OAuth redirect flow. It generated a long tail of broken hobbyist and small-business setups and, like the scoped-apps change it accompanied, deepened the impression that the Dropbox platform demanded ongoing maintenance to keep working.