Scoped apps: developers forced to re-declare permissions and re-auth users
2020–2021
Dropbox replaced its coarse legacy access types with granular OAuth scopes, requiring every developer to revisit their app's permissions in the developer console and, in many cases, have existing users re-authorize before new functionality would work.
What happened
In 2020 Dropbox introduced 'scoped apps,' moving away from a handful of broad legacy access types (such as App Folder and Full Dropbox with implicit capabilities) toward fine-grained OAuth scopes that request specific permissions like files.content.read or members.read. The stated goal was least-privilege access, letting apps ask only for what they need.
The migration was not automatic in effect. Developers had to open the Permissions tab for each app, review the scopes pre-selected from their legacy access type, and deselect anything unused. Crucially, changing the scopes an app declares does not change what a given user has already granted — so to actually gain or adjust permissions, apps had to prompt existing users to re-authorize. For widely deployed integrations this meant a coordinated re-consent campaign, and any app that ignored the change risked calls failing once it needed a scope a user had never granted.
Impact
The scoped-apps migration improved security hygiene but added another item to the running list of mandatory developer chores in the 2020–2021 window — landing alongside the short-lived-token change. For consumer-facing integrations, forcing users back through an OAuth re-authorization screen carried real drop-off risk, and the cumulative churn reinforced the sense that maintaining a Dropbox integration required constant upkeep.
Sources
- 01Dropbox.Tech — 'Now Available: Scoped apps and enhanced permissions'Official / Dropbox
- 02Dropbox.Tech — 'Migrating App Permissions and Access Tokens'Official / Dropbox
- 03Dropbox — 'Customizing scopes in the OAuth app authorization flow'Official / Dropbox