OAuth-Redirect zeigt auf localhost: Google/Microsoft-Credentials reparieren

Wenn n8n beim Verbinden eines Google- oder Microsoft-Kontos den Fehler redirect_uri_mismatch anzeigt oder Sie nach dem Klick auf „Sign in" plötzlich auf http://localhost:5678/... landen, liegt das fast immer daran, dass n8n die Callback-Adresse für den OAuth-Login noch aus den Standardwerten localhost und Port 5678 zusammenbaut, statt aus Ihrer echten öffentlichen Domain. Google oder Microsoft vergleichen diese vom n8n-Server gesendete Redirect-URI mit der Liste, die Sie in der Google Cloud Console beziehungsweise in der Microsoft-App-Registrierung hinterlegt haben, und lehnen den Login ab, sobald beide nicht exakt übereinstimmen. Die Lösung besteht darin, die Umgebungsvariablen N8N_HOST, N8N_PROTOCOL und vor allem WEBHOOK_URL beziehungsweise N8N_EDITOR_BASE_URL korrekt auf die öffentliche Domain zu setzen und die im n8n-Credential-Formular angezeigte Redirect-URI danach unverändert beim OAuth-Anbieter einzutragen. Stand: Juli 2026.

Warum baut n8n die Redirect-URI ausgerechnet aus localhost?

n8n berechnet Editor- und Webhook-Adressen standardmäßig automatisch aus drei Variablen, und ohne eigene Konfiguration greifen dabei laut n8n-Dokumentation zu den Deployment-Umgebungsvariablen die Vorgabewerte http als N8N_PROTOCOL, localhost als N8N_HOST und 5678 als N8N_PORT. Solange Sie n8n nur lokal auf dem eigenen Rechner testen, ist das kein Problem, weil der Browser tatsächlich über localhost zugreift. Sobald n8n aber auf einem Server, in Docker oder hinter einem Reverse Proxy läuft, greift Google oder Microsoft trotzdem noch auf denselben automatisch berechneten localhost-Wert zu, weil n8n von außen nicht weiß, unter welcher Domain es tatsächlich erreichbar ist.

Wie stellen Sie N8N_HOST, WEBHOOK_URL und N8N_EDITOR_BASE_URL richtig ein?

Die zuverlässigste Lösung ist, WEBHOOK_URL manuell auf die vollständige öffentliche Domain zu setzen, denn diese Variable überschreibt laut der n8n-Doku zur Webhook-Konfiguration hinter einem Reverse Proxy die komplette automatisch berechnete URL und wird sowohl im Editor angezeigt als auch bei externen Diensten registriert.

• WEBHOOK_URL: vollständige öffentliche Adresse mit abschließendem Slash setzen, zum Beispiel https://n8n.ihredomain.de/, damit n8n diese Domain statt localhost verwendet.
• N8N_HOST: auf die reine Domain ohne Protokoll setzen, etwa n8n.ihredomain.de, da n8n diesen Wert zusammen mit N8N_PROTOCOL und N8N_PORT für die automatische URL-Berechnung nutzt.
• N8N_PROTOCOL: auf https setzen, sobald Ihr Server per SSL erreichbar ist, da der Standardwert laut Doku http lautet.
• N8N_EDITOR_BASE_URL: die öffentliche URL, unter der Nutzer den Editor erreichen; laut Doku wird sie zusätzlich für E-Mails aus n8n und als Redirect-URL bei SAML-Anmeldung verwendet.
• N8N_PROXY_HOPS: auf 1 setzen, wenn ein Reverse Proxy davorsteht, damit n8n die Weiterleitungs-Header korrekt auswertet.

Nach dem Setzen dieser Variablen muss der n8n-Prozess beziehungsweise Container neu gestartet werden, da n8n Umgebungsvariablen nur beim Start einliest.

Wie beheben Sie den Fehler redirect_uri_mismatch konkret?

Der Fehler entsteht, weil n8n beim Start des OAuth-Flows einen redirect_uri-Parameter an Google oder Microsoft sendet, der nicht mit der beim Anbieter hinterlegten Redirect-URI übereinstimmt, weshalb Sie beide Seiten manuell abgleichen müssen. Öffnen Sie nach dem Neustart von n8n das betroffene Credential erneut und lassen Sie sich die aktuelle OAuth-Redirect-URL anzeigen, die n8n unter dem Pfad /rest/oauth2-credential/callback aufbaut. Kopieren Sie diese Adresse unverändert in die Liste der autorisierten Redirect-URIs Ihres Google-OAuth-Clients oder Ihrer Microsoft-App-Registrierung und speichern Sie dort. Für Google-Verbindungen weist die n8n-Dokumentation zu Google-Drive-Problemen ausdrücklich darauf hin, dass N8N_EDITOR_BASE_URL und WEBHOOK_URL vollqualifizierte Domains verwenden sollten, um genau diesen Redirect-URI-Mismatch zu vermeiden. Verbinden Sie das Credential in n8n danach neu, damit der aktualisierte Token abgerufen wird.

Was gilt zusätzlich, wenn n8n hinter einem Reverse Proxy oder in Docker läuft?

Läuft n8n containerisiert hinter nginx, Traefik oder einem Cloudflare Tunnel, reicht das reine Setzen der Variablen manchmal nicht aus, weil der Proxy die ursprünglichen Header wie X-Forwarded-Proto und X-Forwarded-Host an n8n weiterreichen muss, damit der Dienst intern weiß, dass die Anfrage tatsächlich über https und die öffentliche Domain kam. Prüfen Sie deshalb zusätzlich zur Proxy-Konfiguration, ob N8N_PROXY_HOPS gesetzt ist, denn ohne diesen Wert vertraut n8n den Weiterleitungs-Headern des Proxys nicht und fällt intern wieder auf die Standardwerte zurück. Wer eine n8n-Instanz produktiv mit mehreren OAuth-Verbindungen betreiben will und dabei nicht bei jedem Server-Umzug erneut an Redirect-URIs herumkonfigurieren möchte, profitiert von einem sauber dokumentierten Setup; das ist einer der Punkte, bei denen NordFlux bei der n8n-Einrichtung unterstützt, damit Automatisierungen mit deutscher Datenhoheit auch nach einem Update stabil laufen.

Häufige Fragen zu OAuth-Redirect-Problemen in n8n

Muss ich n8n nach dem Setzen der Variablen neu starten?

Ja, ein Neustart ist zwingend erforderlich, weil n8n Umgebungsvariablen ausschließlich beim Start des Prozesses beziehungsweise Containers einliest. Ohne Neustart bleibt die alte, auf localhost basierende Redirect-URI aktiv, selbst wenn WEBHOOK_URL oder N8N_HOST bereits korrekt gesetzt sind.

Reicht es, nur WEBHOOK_URL zu setzen?

In den meisten Fällen ja, da WEBHOOK_URL laut n8n-Dokumentation die gesamte automatisch berechnete URL überschreibt und damit auch die OAuth-Callback-Adresse korrigiert. Zusätzlich brauchen Sie N8N_EDITOR_BASE_URL nur dann, wenn auch Links in automatisch versendeten E-Mails oder SAML-Redirects noch falsch angezeigt werden.

Warum tritt redirect_uri_mismatch manchmal auch bei n8n Cloud auf?

Auch bei n8n Cloud kann der Fehler auftreten, wenn die im Credential-Dialog angezeigte Redirect-URL nicht mehr exakt mit der beim Anbieter hinterlegten Adresse übereinstimmt, etwa nach einem Wechsel der Workspace-Domain. In diesem Fall hilft es, die aktuell angezeigte Redirect-URI erneut zu kopieren und in der Google Cloud Console oder Microsoft-App-Registrierung zu aktualisieren.

Gilt die gleiche Lösung auch für Microsoft-Credentials?

Ja, das Prinzip ist bei Microsoft- beziehungsweise Azure-Anbindungen identisch, da auch dort ein exakter Abgleich zwischen der von n8n gesendeten Redirect-URI und der in der App-Registrierung hinterlegten Antwort-URL erforderlich ist. Setzen Sie also dieselben Variablen N8N_HOST, N8N_PROTOCOL und WEBHOOK_URL und tragen Sie die im n8n-Credential angezeigte Adresse in die Liste der Antwort-URLs Ihrer Azure-App-Registrierung ein.