Dropbox, Using PKCE

Feature
1

The current version (1.58) doesn't not seem to support the PKCE flow. Are there any plans to add support for this so I am not sharing my App Secret everywhere?

2

hello and welcome to the forum,

https://github.com/rclone/rclone/issues/4792

rclone can encrypt its config file
https://rclone.org/docs/#configuration-encryption

3

While rclone encrypting the config file is nice, dropbox's auth flow repeated recommends using PKCE, I have implemented the PKCE in my own program that generates an rclone config file. The file is then uploaded to a headless node which is running rclone and is able to upload files to dropbox just fine. But during testing to make sure my file matches what rclone produces I was surprised that leaving the client secret blank didn't cause rlcone to use PKCE.

4

as there is already an open issue, why not post there.

what is the practical difference/advantage using or not using pkce?

if someone got hold of your config file created using pkce, can access the dropbox files.
same as using a normal rclone config file

5

Also, thank you for the quick reply.

I'm also concerned that the dropbox access token will not be automatically refreshed as I can't find code to do that anywhere in the rclone code and can't find a command to tell rclone to refresh the access token immediately to test it quickly. I am able to use curl to get a new access token by copying the refresh token that is in the config. At this point I am just going to run a test overnight to see if my node keeps uploading even after the current access token expires just to see if automatically refreshes.

6

rclone will refresh the token on its own, same as with gdrive, onedrive and so on.

7

I didn't see that issue when I was creating this post, I looked through all the open topics that were related but I guess I failed to look at the issues.

As for the practical issues I find most of them to be dropbox made:

  • Our software should follow recommendations of the services we are using for best compliance, and dropbox recommends this. (Caused by dropbox)
  • Since I didn't want to launch another server on the local system I had the installer register a different protocol handler in the windows registry so our program will respond directly to the redirect uri. This is only allowed when using the PKCE flow. (dropbox enforces this)
  • If our app secret is available then someone else could impersonate our app profile and have a victim think they are authenticating our client. Yes if a customer's config file is compromised then the attacker could gain access to the customer's files but the config file is not easily accessible while the app secret would be extractable from our software/installer which is much more readily available. (This is also a weak argument because the client id could also be used to phish and is required to refresh the tokens).

Most of this is moot since I will continue to use my implementation for our customers since it is streamlined for our offered services and does not require using a terminal/console interface. But for testing and internal usage having rclone support PKCE is probably a recommended path. (Once I can get familiar with rclone and golang I may be able to add it in.)

8

I was just dubious as I was examining the code but granted I am not familiar enough with the rclone code so I am sure I will be satisfied by the morning, after I have seen it happen.

Thank you.

9

thanks,

that issue is mentioned in this topic
https://forum.rclone.org/t/dropbox-refresh-token-support/20600

10

I don't think there is an open issue for this, so if you want to make a new issue on Github that would be great.

Even better if you wanted to implement it! Ideally we could add it as an option to the existing oauth flow and make it available to all the oauth using backends.

I haven't really got my head around it though...

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.