The most common root cause
The redirect URI in Google Cloud does not exactly match the redirect URI n8n is using. Scheme, hostname, port, path, and trailing details matter. Fix the public URL first if n8n is generating the wrong callback.
Map the OAuth flow before changing anything
When you click "Sign in with Google" from an n8n credential, several systems participate. Google redirects the browser back to n8n with a short-lived authorization code. n8n then exchanges that code for tokens and stores the credential. If any endpoint, client setting, consent rule, or scope is inconsistent, the setup can fail even though every individual screen looks reasonable.
Work this checklist in order
- Copy the redirect URI shown by n8n.
Use the callback URI n8n provides for that credential type. Do not invent one from memory. - Compare it character-for-character with Google Cloud.
Open the OAuth 2.0 Client ID in Google Cloud and inspect the authorized redirect URIs. HTTPS vs HTTP, subdomain differences, ports, and paths all matter. - If the n8n URI is wrong, fix n8n first.
A self-hosted instance behind a reverse proxy or tunnel may generate callbacks using an internal host, localhost, HTTP, or the wrong port. Correct the public URL/proxy configuration before adding bad callback URLs to Google as a workaround. - Verify the right OAuth client type.
For browser-based OAuth callbacks, the client configuration must support the web redirect flow you are actually using. - Check the consent screen and user status.
If the app is still in testing, only permitted test users may be able to authorize it. Workspace administrators can also impose organization-level restrictions. - Enable the Google APIs the credential actually needs.
A valid OAuth client does not automatically enable Gmail, Sheets, Drive, Calendar, or other service APIs in the project. - Check scopes and app restrictions.
Request only what the workflow needs. Sensitive or restricted scopes can create additional Google review and policy requirements, especially for broadly distributed apps. - Reauthorize after material changes.
If you changed scopes, OAuth client settings, account permissions, or the public callback URL, recreate or reconnect the n8n credential rather than assuming the stored token will inherit the change.
Common error patterns and what they actually suggest
| Symptom | Likely area | First check |
|---|---|---|
| redirect_uri_mismatch | OAuth client / public URL | Exact authorized redirect URI in Google Cloud |
| Access blocked / app not verified | Consent screen / user eligibility / scopes | Publishing status, test users, Workspace restrictions |
| Connection works, then later fails | Refresh token / revoked access / app testing behavior | Credential reauthorization and token lifecycle |
| Google login succeeds but node gets 403 | API or permission | Enabled API, granted scopes, file/account permissions |
| Callback points to localhost or HTTP | Self-hosted n8n / reverse proxy | External editor/webhook URL and proxy headers |
Self-hosted n8n creates an extra failure surface
Cloud-hosted automation products control the public callback hostname for you. Self-hosting gives you more control, but now your deployment owns DNS, TLS, reverse-proxy behavior, public URL generation, uptime, persistence, and upgrades. OAuth is often the first place a nontechnical builder discovers that distinction.
If the OAuth callback is wrong, resist the temptation to solve it by registering several variations in Google Cloud. Get the public identity of the n8n instance correct so webhooks, callbacks, links, and other integrations agree on the same external URL.
Why a credential can work for one Google service and fail for another
"Google OAuth works" is not a single state. Different nodes may depend on different APIs, scopes, resource permissions, or account policies. A successful Gmail credential does not prove that a Sheets or Drive workflow has the access it needs.
- Confirm the target API is enabled in the same project.
- Confirm the n8n credential type requests the scopes required by that node.
- Confirm the signed-in account can access the target mailbox, file, shared drive, calendar, or spreadsheet.
- Check Google Workspace admin restrictions if the account is managed.
Do not solve production OAuth with a personal super-user account
It is easy to make a workflow work by authorizing it with an owner or administrator account that has broad access. That creates a different problem: the automation inherits privileges it may not need, and the business becomes dependent on a person's identity and token.
Production design question
Before deploying, decide whose identity the workflow should represent, what resources it should access, how credentials are rotated or revoked, and what happens when the original employee leaves.
If OAuth is only the first broken layer
Once authentication works, you may still face API limits, inconsistent payloads, duplicate events, missing fields, AI output problems, retries, or failure notifications. That is normal. OAuth is the door into the system, not the system itself.
Related White Paper
Why Is My AI Automation Breaking?
A field guide for tracing failures across triggers, credentials, APIs, models, data, and downstream actions.
