I just stumbled on this thread while writing some scripts to help my with syncing my large Google Drive.
There is a class of users for whom "create your own client ID" is not possible, and I haven't seen it mentioned in this thread:
Accounts enrolled in Google's Advanced Protection Program (APP)
I'm one of them, and I tested this thoroughly today before posting.
Here's my experience. Personal Cloud project, Drive API enabled, OAuth consent screen configured, Desktop-app client, me as the app's sole author and user:
- scope
drive.readonly, publishing status "In production" -> Error 400: policy_enforced, "Access blocked: app is not approved by Advanced Protection" - same scope, status "Testing", my own address added as test user, scopes declared on the consent screen -> identical error
- scope
drive.file(non-sensitive tier) -> consent succeeds, token works
So APP blocks any unverified app requesting a sensitive or restricted scope.
It does not matter that I registered the client, that I'm the developer, or what the publishing status is. drive.file passes but is useless for sync. The token sees zero existing files (I checked: lsf and backend query return nothing until the app creates files or you pick them one by one in Google's Picker).
Before anyone suggests the usual fixes:
- Verification is not the gate. Leaving the bureaucracy aside, client-ids that work under APP (rclone's, Thunderbird desktop's) belong to verified apps. But verification alone doesn't put you on the APP allowlist. Thunderbird for Android - same organization, same Gmail scope - has been blocked since 2024 (thunderbird/thunderbird-android#8256). The allowlist appears to be per-client-id, hand-curated, and unreachable. Even Google's own Apps Script CLI is blocked (google/clasp#946).
- Service accounts: Tried but cannot see Shared-with-me, and need every folder shared to them by hand. Clumsy and not a proper mirror.
- Workspace migration: Admin-trusted client IDs supposedly work under APP (not tested today to be honest), but moving a consumer account to Workspace orphans every Shared-with-me grant tied to the @gmailgmail identity, so it's not a reasonable workaround for most people, including myself.
- Drive for Desktop: no Linux, no headless, no Shared-with-me, gdocs become stubs. Wholly inferior to rsync (which is why we are here).
- App passwords: revoked under APP, and never covered the Drive API anyway.
Which leaves the uncomfortable conclusion: rclone's built-in client ID currently works for users like me because it's on Google's internal allowlist. When it's retired, APP users go from "works fine" to "no path at all".
If there is an open line to Google about this change: could this user class be put on the table? The fix on Google's side is small and already exists for Workspace - admins can mark a client ID as trusted. A consumer-account equivalent ("I am the author of this app, I trust it") would resolve it. Failing that, some successor to the allowlisted shared credential.
And if anyone here with Advanced Protection has successfully moved to their own client ID, I'd genuinely like to hear how, because I just spent a whole day on it and could not find any success stories elsewhere.