Best practice for keeping OAuth2 client_secret confidential

[ncw (Nick Craig-Wood)]

However, my problem is this: from an OAuth2 perspective, client_secret should be kept confidential and hence should not be saved within rclone.conf (or even any other means which can be ‘sniffed’ by a Process Monitor or similar).

You can encrypt the config file, but the use will need to know the decryption password.

I looked up how RClone keeps its own client_secret to try and see if there’s a way to do it securely, but from what I understand it seems that rcloneEncryptedClientSecret is simply obscured by a hard-coded key cryptKey inside obscure.go.

That is correct. It isn’t an ideal solution, but in my opinion the client_secret isn’t that important. It doesn’t allow access to any other data, all it does is identify the client. If compromised then your client can be spoofed which I don’t think is a big deal.

For example, is it possible to provide an “Access Token provider” (i.e. URL / command-line) which RClone would call whenever it needs an Access Token, instead of filling refresh_token + client_secret in rclone.conf?

An interesting idea…

Maybe it could be generalised for every config variable, so if there was backend_setting then backend_setting_command would be a command to run to read it. Probably not too tricky…

I realize this may be a complex question, but exposing client_secret on a desktop application is a blocker from a security perspective.

You can pass config to rclone via environment variables , command line options, and the config file all of which are visible to the determined user. rclone could potentially overwrite sensitive environment variables I suppose.

Actually I think I may have found a solution: directly writing the “access_token” into rclone.conf along with some dummy refresh_token.

That will work, but long running transfers (running longer than the token age) will need a refresh token.