This isn’t a Google OAuth issue, it’s an n8n Cloud behavior mismatch.
In n8n Cloud, you cannot reliably use a custom Google OAuth client for Google Drive the same way you do in self-hosted. Even if the consent flow completes, n8n Cloud injects its own internal OAuth flow name and state, which changes the effective redirect URI at runtime.
That’s why you’re seeing:
/rest/oauth2-credential/callback
vs
/rest/oauth2-credential/callback?flowName=GeneralOAuthFlow
Google treats those as different redirect URIs. Adding only the base path will still fail.
What actually works (tested patterns)
Option 1 - Correct fix (recommended)
Use n8n Cloud’s built-in Google credentials, not a custom OAuth client.
n8n Cloud is already registered and compliant with Google’s OAuth policy. This avoids redirect mismatches entirely.
Option 2 - If you must use your own OAuth client
You must register ALL possible redirect variants in Google Cloud Console, including:
https://advaitsingh79.app.n8n.cloud/rest/oauth2-credential/callback
https://advaitsingh79.app.n8n.cloud/rest/oauth2-credential/callback*
Google UI doesn’t document this well, but n8n appends query params dynamically. If Google doesn’t see an exact match, it hard-fails.
Option 3 — Full control (advanced / production)
Self-host n8n and explicitly set:
-
N8N_HOST
-
WEBHOOK_URL
-
N8N_EDITOR_BASE_URL
Then register one static redirect URI. This is the only setup where custom OAuth is fully predictable.
Why this keeps confusing people
n8n Cloud abstracts OAuth for security and multi-tenant reasons. The UI suggests a static redirect URL, but internally the flow name is dynamic. That’s why the docs + logs feel contradictory.
If you want custom OAuth + zero surprises, self-hosting is the line where everything snaps into place.