If I login to a mobile/web app with a Google account, what stops the developer also using that account?

Question

I have an admittedly-vague understanding of how OAUTH works, but I recently went through the rigmarole of installing rclone and having it sync some files from my Google Drive to my Linux laptop.

As part of rclone's documentation, it is recommended that I create my own Google App in their developer portal, and populate my local rclone config with the Client ID and Client Secret of that Google App. I presume this was so that any usage would be specific to me, e.g. for billing/usage-limits purposes, and not some generic rclone app instance (although that option was also available). The Google App remains in 'testing' mode, and only my Google email address is listed as a test user. When configuring rclone with access to my Google Drive, I was redirected to a Google login screen populated with the details of my Google App, and received some warnings/confirmations about how my Google App wasn't verified yet.

Since I am the only holder of that ID and Secret (assuming nothing nefarious on rclone's part, nor any compromise of my laptop), am I right in thinking that only I can actually access that Google Drive (bar Google themselves) via that configuration?

If I were to use rclone's default settings (presumably using their Google App ID/Secret, internally), what (if anything) is stopping the developers/controllers of that Google App from accessing my Google Drive, behind the scenes, outside of my intended usage of their app?

I also have a Windows application and an Android app, which both also sync files from my Google Drive. Those apps presented the Google login screen populated with their own details, and don't offer the opportunity to configure my own Client ID/Secret (so I assume I am using theirs, internally).

Are my Google-related files or services any more or less available to the developers of the Windows and Android apps (using their Client ID/Secrets), than they are to the rclone developers (using mine)?

Specifically, why?

Would that position change if the "app" was a website (e.g. if the website's Client ID/Secret were in a discoverable config file)?

Answer 1

am I right in thinking that only I can actually access that Google Drive

Yes, assuming that rclone runs locally on your device (no server-side component) and hasn't uploaded the access token to some server (which would be extremely sketchy of it!).

Are my Google-related files or services any more or less available to the developers of the Windows and Android apps (using their Client ID/Secrets), than they are to the rclone developers (using mine)?

It depends. If the Windows/Android apps are running locally with no remote backend (and aren't uploading their access token to some remote server anyhow, or otherwise phoning home user data), then their developers have no more access than rclone's developers. If instead the apps have a developer-owned backend and the app is merely a frontend rather than a "full" client app, then they have access to whatever you authorized when doing OAuth (although not to your Google credentials, unless the app was written very incorrectly).

---

why?

Client ID and Client Secret don't do anything at all past the initial step of authorizing access. They exist only for two reasons: to tell the OAuth provider (Google) what app is requesting access (and thus what it should show the user at the confirm-access screen, and where it should do things like send the redirect), and so that the user can later see what app's they've authorized and what those apps have done (and revoke access, if needed). After the OAuth process is completed, it's purely a question of who has the access token. Did the token go to your device (only), or did it go to the developer's machine (backend server)?

For thick clients / local apps with no "cloud" component (they may access third-party cloud services like GDrive, but all of the app's computation happens on your machine), it really doesn't matter what OAuth "app" you use. The access token is provided directly to your machine no matter which client id+secret pair you use. The app could (hopefully doesn't) then upload the access token to some dev-owned servers (which would give the developers access to whatever the access token is authorized for, of course), but absent it doing that, the developer has no access to your account at all... no matter whose "Google App" is used.

(Note that, as a practical matter, you can't meaningfully use a client secret with apps like that; there's nowhere to store it that the users can't extract, so it isn't a secret any more. Thus, locally-run apps - including in-browser apps with no server-side logic - that want to use OAuth don't use the Authorization Code flow and instead use something like PKCE.)

For cloud-based software (SaaS), you usually can't avoid giving the server the access token. There's ways to work around that - you authenticate in the client first to the client's server, then OAuth to the third-party service from the client, and relay anything that the server needs through the client directly - but that's not the pattern I usually see. It's scenarios like that, where there's a callback that sends the auth code to the back-end rather than to the client, and then the back-end uses the OAuth client secret to exchange the code for an access token, that are what the Authorization Code flow is for. In those scenarios, the backend server of the app you're using has access to whatever you've authorized (which is generally "whatever their Google App [or similar] requests"). It still won't have full access - if implemented correctly, OAuth prevents the client from seeing the credentials, so they can't just log in as you and get unfettered access - but it'll have whatever access was granted at the OAuth confirmation screen. Because scenarios like that (SaaS or similar, with a backend) hold the client secret on the backend, you generally can't (and shouldn't try to) set up your own OAuth app (Google app or whatever) for them, as you'd have to give the server your personal app's client secret and that completely misses the point.

Answer 2

When you use your own Google App for authentication with rclone, it means that only you (and potentially Google) can access your Google Drive using that app. This is because the Client ID and Client Secret are unique to your app, and are used to authenticate and authorize access to your Google Drive.

If you were to use rclone's default settings, it would use its own Google App for authentication. In this case, the developers or controllers of that Google App would not have access to your Google Drive, unless you explicitly grant them access. This is because the app would need to be authorized by you, the user, to access your Google Drive.

The same applies to the Windows and Android apps that you mentioned. If they use their own Client ID and Secret for authentication, then the developers of those apps would not have access to your Google Drive unless you explicitly grant them access.

Whether the app is a website or a desktop application, the principles of authentication and authorization remain the same. In both cases, the app would need to be authorized by you, the user, to access your Google Drive. If the app uses its own Client ID and Secret for authentication, then the developers of the app would not have access to your Google Drive unless you explicitly grant them access.