I have a self hosted n8n running on local Raspberry. I access it by domain name from my other PC, so that if and when the IP changes, I don’t have to hard code it. So essentially, from my PC, I can always target n8n via http://raspidomainname:5678/
n8n is run in a Docker compose stack with these envs:
I have then created a Web App on GCP following the docs and have the Client ID and Secret at hand, with the app published (not in testing). Now, when I create a n8n credential, this shows:
On my PC, if I continue to sign in, eventually the final redirect errors with “connection refused” because my PC is not where n8n is running, so I have to run on a shell:
ssh -L 5678:127.0.0.1:5678 myuser@raspidomainname
That way, the redirect reaches the end, but errors with Unauthorized.
This is weird because it was running fine before upgrading to 2.4.8 from … well, unfortunately I have forgotten, but I believe it was 1.1xy, more or less around October 2025.
Hi @tamy.santos , unfortunately I can’t do that, otherwise the redirect URI generated by n8n has a domain name in it and GCP does not accept it (Invalid redirect: must end with a public top-level domain (e.g. .com or .org).)
Mine is not public because the Raspberry is not exposed to the internet
Thanks for the extra details, this actually confirms what’s happening.
At this point, there isn’t a misconfiguration left to fix in n8n. The OAuth flow is being started on one origin and completed on another, so the callback is correctly rejected as unauthorized.
This is expected behavior.
Why This Happens
If your n8n instance can’t be reached through a public, consistent URL, then Google OAuth (for Gmail) simply isn’t compatible with this setup.
This is a constraint of Google’s OAuth protocol, not a regression or bug in n8n.
What Are Your Options
The only remaining thing to validate is whether your use case can switch away from OAuth. For example:
Service Account authentication (if your use case supports it)
Another auth method that doesn’t require a public callback URL
If OAuth is mandatory for your workflow, then unfortunately the architecture has to change to support a publicly accessible, consistent URL for callbacks.
I understand, but the ssh tunneling command should work for that, or at least it used to.
I tried authenticating directely from the browser of the Pi and the flow succeded, so I guess the problem really lies in the tunneling, considering I will mostly (when needed) perform the oauth flow from my PC, which is more convenient.
Nevertheless, @tamy.santos I’m grateful for your clarifications, if I find a proper solution I’ll update the thread.
The OAuth flow succeeds on the Pi because the browser, n8n, and the callback all resolve to the same host. When started from your PC, the SSH tunnel only forwards traffic, but the browser-visible callback address still doesn’t match, so OAuth correctly rejects it.
So the tunneling isn’t “broken”, it’s just not compatible with completing a browser-based OAuth flow from another machine. For this setup, running OAuth directly on the Pi is the supported option unless you expose n8n via a real public HTTPS URL.
Thanks for closing the loop, and feel free to update the thread if you end up using a public tunnel or similar solution.
