Ich betreibe mehrere n8n-Instanzen (dev / rec / prod) und verwende Microsoft Entra ID-Anmeldedaten, um Microsoft Graph abzufragen (Chats nach Benutzer-ID auflisten, Chat-Mitglieder abrufen, usw.).
Wenn ich einen Workflow von n8n-dev zu n8n-rec bereitstelle, schlägt der Workflow systematisch beim ersten geplanten Durchlauf fehl mit: “refreshToken is required” / ERR_ASSERTION.
Die einzige Möglichkeit, das Problem zu beheben, besteht darin, die Anmeldedaten manuell zu öffnen und auf der Zielinstanz auf “Reconnect” zu klicken. Nach einigen Stunden oder der nächsten Bereitstellung tritt das Problem erneut auf.
Ich vermute, dass es sich um die Kombination von drei bekannten Verhaltensweisen handelt, aber ich möchte eine Bestätigung vom n8n-Team und Best-Practice-Richtlinien für ein Multi-Environment-Setup erhalten.
Was ich vermute, dass geschieht
-
Anmeldedaten werden nicht mit Workflow-Exporten übertragen. Die Workflow-JSON enthält nur eine Anmeldedaten-Referenz (ID + Name), nicht das verschlüsselte Token-Blob. Dies ist das erwartete Verhalten.
-
Source Control & Environments schließen Anmeldedaten ausdrücklich aus. Gemäß der offiziellen Dokumentation ( External secrets | n8n Docs ): “Diese Funktion unterstützt nicht die Verwendung unterschiedlicher Anmeldedaten in verschiedenen Instanzen.”
-
Microsoft Entra verwendet Refresh-Token-Rotation. Jeder Refresh-Aufruf invalidiert das vorherige refresh_token und stellt ein neues aus. Wenn der gleiche Anmeldedaten-Datensatz auf zwei Instanzen vorhanden ist (dev + rec), verbrennt die Instanz, die zuerst aktualisiert wird, das Token der anderen, was zu “refreshToken is required” auf der zweiten führt. Dies wird in Issue #26453 dokumentiert ( Microsoft Outlook OAuth2 token refresh fails after ~1 hour on n8n Cloud, masked by dummy.stack.replace error · Issue #26453 · n8n-io/n8n · GitHub ): “Microsoft Entra ID ersetzt Refresh-Tokens bei jeder Verwendung durch ein frisches Token. Wenn n8n das neue Refresh-Token nicht speichert, können nachfolgende Refresh-Versuche fehlschlagen.” Es wird auch auf dem Entra ID-Node im Community-Thread #193787 ( Entra ID node reconnection issues ) und Issue #14426 (Microsoft Entra Component auth failure. · Issue #14426 · n8n-io/n8n · GitHub) reproduziert.
Der Node ist ein HTTP Request-Node, der auf https://graph.microsoft.com/v1.0/users/{id}/chats zeigt und den vordefinierten Anmeldedatentyp Microsoft Entra ID (Azure Active Directory) API verwendet.
Workflow
WORKFLOW-EINGABE → CHATS NACH BENUTZER-ID AUFLISTEN (HTTP Request, Graph API, fehlgeschlagen hier) → LISTENWERT AUFTEILEN → ÜBER CHATS SCHLEIFEN → CHAT NACH THEMA FILTERN → falls wahr: CHAT-MITGLIEDER ABRUFEN → BENUTZERINFORMATIONEN / falls falsch: OFF-TOPIC-CHAT-NAME → ENDE DER SCHLEIFE.
Willkommen @Rodolphe24 in unserer Community! Ich bin Jay und ich bin ein verifizierter n8n Creator.
Deine Ursachenanalyse ist genau richtig. Microsoft Entra ID nutzt Refresh-Token-Rotation, daher invalidiert die Umgebung, die den Token-Endpunkt zuerst aufruft, das Token in der anderen Umgebung. Die Lösung besteht darin, jede Umgebung als vollständig separate OAuth-App zu behandeln – erstelle eine separate App-Registrierung in Azure für dev und eine weitere für rec, jeweils mit eigener Client-ID/Secret und eigener Redirect-URI, die auf die n8n-Instanz dieser Umgebung verweist. Teile niemals denselben Anmeldedatensatz über Instanzen hinweg. Wenn du das eingerichtet hast, verwaltet jede Umgebung ihren eigenen Refresh-Zyklus unabhängig und die Token-Invalidierung hört auf.
Guten Morgen @Rodolphe24
ich würde auch vermeiden, Workflows zu promoten und zu erwarten, dass die Anmeldedaten mitgehen. Was ich in solchen Szenarien normalerweise mache, ist, den gleichen logischen Namen der Anmeldedaten in dev/rec/prod beizubehalten, aber die Anmeldedaten lokal in jeder Instanz neu zu verbinden/zu erstellen, wobei ich die App Registration dieser Umgebung verwende. Auf diese Weise bleibt der Workflow leicht über Source Control zu promoten, aber jede Umgebung behält ihren eigenen OAuth-Status und ihren eigenen Token-Refresh-Zyklus. Es lohnt sich auch zu überprüfen, ob der importierte Workflow nach dem Pull/Deploy auf die richtige Anmeldedaten in der Zielumgebung verweist.
Danke für deine Eingabe — das ist tatsächlich das Muster, das ich bereits verwende:
-
Gleicher logischer Credential-Name über dev/rec/prod
-
Separate Azure App Registration pro Umgebung
-
Jeder Credential wird lokal auf seiner eigenen Instanz neu verbunden
Nach dem Deploy verweist der Workflow auf den korrekten Credential auf dem Ziel. Bevor ich den Workflow veröffentliche, habe ich ihn bereits erfolgreich gestartet. Deshalb verstehe ich es nicht…
@Rodolphe24
Ich würde zwei Dinge untersuchen: ob die Anmeldedaten beim Neuverbinden wirklich einen Refresh-Token erhalten, besonders mit korrektem offline_access/admin consent, und ob alle Container/Worker derselben Instanz denselben N8N_ENCRYPTION_KEY verwenden.
Hallo, danke für dein Feedback. Könnte das ein Problem mit einem n8n Worker sein? Wenn ich den Workflow manuell ausführe, funktioniert er einwandfrei. Wenn ich den Hauptworkflow jedoch nach dem Veröffentlichen über einen Scheduler-Node auslöse, erhalte ich einen Fehler beim Refresh Token.
Ja, das ist sehr wahrscheinlich ein Worker-Problem. Wenn ein geplanter Workflow über einen Worker ausgeführt wird, benötigt der Worker den exakt gleichen N8N_ENCRYPTION_KEY wie die Hauptinstanz, um gespeicherte Anmeldedaten zu entschlüsseln. Wenn diese unterschiedlich sind, schlägt die Token-Entschlüsselung fehl und du erhältst einen Refresh-Token-Fehler. Überprüfe die Umgebungsvariablen deines Workers und stelle sicher, dass N8N_ENCRYPTION_KEY mit der Hauptinstanz übereinstimmt. Stelle auch sicher, dass der Worker Zugriff auf die gleiche Datenbank hat, in der die Anmeldedaten gespeichert sind – ein Worker, der sich mit einer anderen Datenbank verbindet, wird das Token überhaupt nicht sehen.
Beobachtung zum refreshToken-Fehler
Ich habe mehrere Tests zum Fehler refreshToken is required durchgeführt:
-
Test 1:
In der n8n-rec-Instanz mit Nur-Lese-Berechtigung schlägt der Workflow-Start mit dem folgenden Fehler fehl:
refreshToken is required
-
Test 2:
In der n8n-rec-Instanz mit Lese-/Schreibberechtigung führt der Workflow-Start zum gleichen Fehler:
refreshToken is required
-
Test 3:
Nach manuellem erneuten Verbinden von Microsoft Entra ID in der n8n-rec-Instanz mit Lese-/Schreibberechtigung startet der Workflow erfolgreich ohne Fehler.
Der Fehler tritt in der n8n-dev-Instanz mit Lese-/Schreibberechtigung nie auf, Workflows werden veröffentlicht.
@Rodolphe24 Großartig dein Test-Breakdown. Dein Test-3-Ergebnis ergibt Sinn — wenn du die Credential auf n8n-rec manuell neu verbindest, stellt Microsoft einen neuen OAuth-Token aus, der den Scope offline_access enthält (notwendig für Refresh-Token). Die alte Credential, die in n8n-rec gespeichert war, hatte wahrscheinlich einen abgelaufenen oder Scope-beschränkten Token aus dem ursprünglichen Setup.
Das Wichtigste zum Mitnehmen: Wenn das Neu-Verbinden auf n8n-rec mit Read/Write funktioniert, fehlte der ursprünglichen Credential der Scope offline_access. Um zu vermeiden, dass das wiederholt vorkommt, stelle sicher, dass deine Azure App Registration diesen Scope aktiviert hat und autorisiere neu auf jeder Instanz separat.
- Erstelle separate App-Registrierungen in Azure: Eine für Dev, eine für Rec, eine für Prod.
- Injiziere deine Client-Konfiguration in deine verschiedenen n8n-Server-Instanzen mithilfe von Standard-Umgebungsvariablen:
MICROSOFT_CLIENT_IDMICROSOFT_CLIENT_SECRETMICROSOFT_TENANT_ID
- Wechsle in deinem HTTP-Request-Node den Authentifizierungstyp zu Generic Credential Type → OAuth2.
- Verwende in den Credential-Konfigurationsfeldern n8n-Ausdrücke, um auf deine Umgebungsvariablen zu verweisen:
- Client ID:
{{$env.MICROSOFT_CLIENT_ID}}
- Client Secret:
{{$env.MICROSOFT_CLIENT_SECRET}}
Da n8n Umgebungsvariablen nativ pro Instanz auswertet, bleibt deine Workflow-JSON identisch über Dev, Rec und Prod, aber jede Instanz kommuniziert mit ihrem eigenen isolierten Azure-Container.
Sag mir Bescheid, ob das für dich funktioniert, sonst habe ich noch eine andere Lösung.
Ok, danke für dein Feedback. Ich werde das mal testen.
Hallo, danke für dein Feedback, das ist leider nicht möglich, weil ich die spezifische Authentifizierung auf Basis von Microsoft Graph verwenden muss: Microsoft Entra ID (Azure Active Directory) API, die ebenfalls auf OAuth2 basiert
Freut mich, dass meine Antwort hilfreich war und als Lösung ausgewählt wurde – das hat mir den Tag wirklich verschönert!
Wenn du weitere Fragen zu diesem Thema (oder anderen n8n-Setups) hast, melde dich gerne bei mir. Ich helfe gerne weiter.
@Rodolphe24
Enthält die REC-Anmeldedaten nach dem Deploy, bevor Sie auf „Reconnect
Hallo zusammen,
Entschuldigung für die verspätete Antwort, ich war in letzter Zeit ziemlich beschäftigt.
Um dieses Thema abzuschließen: Nachdem wir n8n durch mehrere neuere Versionen aktualisiert haben, scheint das Refresh-Token-Problem, das wir beim Übertragen von Workflows aus unserer n8n-dev-Umgebung zu n8n-rec hatten, verschwunden zu sein.
Wir konnten das Problem seit den Upgrades nicht reproduzieren, daher sieht es so aus, als könnte es in einer der neueren Versionen behoben worden sein.
Danke an alle für eure Hilfe und Einblicke in dieser Diskussion.
Mit freundlichen Grüßen
