You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.

Forum Discussion

fietserwin's avatar
fietserwin
Explorer | Level 4
4 years ago

What way of authorization to use for a (PHP) open source module

I am the developer of the Drupal module Backup & migrate Dropbox that extends the "Backup and migrate" module to store backups on Dropbox. So this module: is open source, so I cannot put the App se...
  • Greg-DB's avatar
    4 years ago

    While the PKCE flow is generally meant for client-side apps (and server-side apps would generally use the code flow) given the constraints in this case, using the PKCE flow seems reasonable and should work.

     

    The issue you're running in to here is that you're calling /oauth2/token to perform 'grant_type=refresh_token' but are supplying the 'code_verifier' parameter. The 'code_verifier' parameter should only be provided for the initial 'grant_type=authorization_code'.

     

    That is, the flow should look like this:

    • The user is directed to /oauth2/authorize
    • The user approves the app
    • The user copies the authorization code from the Dropbox web site into the app
    • The app calls /oauth2/token supplying 'code' set to the authorization code, 'grant_type=authorization_code', 'code_verifier' set to the code verifier, and 'client_id' set to the app key, just once per authorization flow.
    • The app uses the short-lived access token to make API calls.
    • The app calls /oauth2/token supplying 'refresh_token' set to the refresh token, 'grant_type=refresh_token', and 'client_id' set to the app key, but not 'code_verifier', repeatedly whenever a new short-lived access token is needed.

    Also, to confirm, yes, refresh tokens are long-lived. They don't expire by themselves, but can be revoked on demand.

     

    Hope this helps!