Safety of storing a Google OAuth 2.0 client_id/secret on an end-point

Off Topic
1

Hello everyone

I am not sure this is entirely off-topic, but just in case.

It has been discussed in a few other threads that storing client secret should not be a security risk. However, all documentation and tutorials I see about OAuth 2.0, specify that secret should be kept as secure as possible and treat it as a password.

Sure, the user will still need to authenticate, but apparently there are some attacks that can hijack the OAuth flow and act maliciously. For example, it can present itself as rclone (or the custom app if you create your own OAuth creds) and phish the user into authenticating.

Any thoughts on this?

Also, does anybody know if in Google Cloud Platform, there can be some IP restriction put in place? There is for API Keys, but I can't see any for OAuth 2.0 creds. There is one thing called "VPC Controls" but I don't get it 100%.

All feedback is welcome! :slight_smile:

Cheers,
M

2

hi,

then encrypted the rclone config file.

intead of oauth/token, use a service file.

with s3 providers, i have done that using user/bucket polices.
as far as i can tell, cannot use that approach with gcloud.

so would need use VPC.
Can I restrict which IP address can access objects in a bucket?