n8n-Zugänge: Wo die Domain-Freigabe nicht wirkt

Um API-Schlüssel und OAuth-Verbindungen in n8n abzusichern, legen Sie für jeden Workflow fest, welche Identität er verwendet, wer Zugriff auf Credential und Workflow erhält und welche Domains ein HTTP-Request-Node mit dem Credential ansprechen darf. Die n8n-Dokumentation zu Credentials zieht dabei eine Grenze: „Allowed HTTP Request Domains“ gilt für die Verwendung im HTTP-Request-Node, nicht im dedizierten App-Node.

Ein Rechteplan muss deshalb Verbindung, Freigabe und Node getrennt erfassen. Ein gespeichertes Credential legt weder fest, wer einen damit verbundenen Workflow ausführen kann, noch ersetzt seine Domainliste die Berechtigungen des Kontos beim angebundenen Dienst. Gerade bei KI-Workflows, die mehrere Dienste nacheinander aufrufen, entscheidet jeder verwendete Node darüber, welche Kontrolle tatsächlich greift.

Festes Konto oder nutzerbezogene OAuth-Verbindung wählen

Klär en Sie zuerst, in wessen Namen der Workflow handeln soll. Bei einem „Fixed credential“ verwendet er unabhängig von der ausführenden Person dieselbe Verbindung; das ist die Voreinstellung. Bei einem „End-user credential“ wird zur Laufzeit die Verbindung der Person verwendet, die den Workflow auslöst. Die Auswahl zwischen diesen OAuth-Typen steht in n8n Cloud Enterprise und selbst gehostetem Enterprise zur Verfügung.

Für einen automatisierten Teamprozess mit einer gemeinsamen Dienstidentität kann eine feste Verbindung passen. Soll der Ablauf dagegen auf Daten der jeweils auslösenden Person zugreifen, ist eine nutzerbezogene Verbindung die passendere Zuordnung, sofern die Funktion verfügbar ist. Wird ein solches Endnutzer-Credential geteilt, verbinden die Berechtigten ihre eigenen Konten; sie übernehmen nicht die bestehende Kontoverbindung der Person, die es geteilt hat.

Unabhängig vom Typ sollten Sie beim angebundenen Dienst nur die benötigten Rechte vergeben. Braucht ein Workflow Daten lediglich zu lesen, prüfen Sie dort, ob sich Schreibrechte vermeiden lassen. Benennen Sie das Credential nach Dienst, Konto und Zweck: So lässt es sich später einem Ablauf zuordnen, ohne geheime Werte öffnen zu müssen.

Credential dem richtigen Projekt oder Nutzer zuordnen

Ein Credential kann direkt für ausgewählte Personen oder für ein Projekt freigegeben werden. Laut der n8n-Anleitung zur Credential-Freigabe können Berechtigte eine geteilte Verbindung in eigenen Workflows verwenden, ohne deren geheime Details anzusehen oder zu bearbeiten. Bei einer Projektfreigabe können alle Mitglieder dieses Projekts das Credential verwenden; die direkte Freigabe richtet sich an bestimmte Nutzer.

Erstellen Sie eine Verbindung, die einem Team gehören soll, nach Möglichkeit gleich im passenden Projekt. Wird sie im persönlichen Bereich angelegt, prüfen Sie bewusst, mit wem sie anschließend geteilt wird. In der Community-Version werden neue Credentials im persönlichen Bereich erstellt. Credential-Freigaben sind in allen n8n-Cloud-Plänen sowie in selbst gehosteten Business- und Enterprise-Installationen verfügbar.

Für die Freigabe öffnen Sie unter „Credentials“ den betreffenden Eintrag und wählen „Sharing“. Im Feld „Share with projects or users“ fügen Sie die benötigte Person oder das Projekt hinzu und speichern. Das vom Ersteller gehaltene Credential kann dessen Eigentümer teilen; bei einem Credential, das einem Projekt gehört, dürfen dies nur Projektadmins. Instanzinhaber und Instanzadmins können Credentials der gesamten Instanz ansehen und teilen. Vor einer Projektfreigabe zählt daher auch, wer Mitglied dieses Projekts ist.

Die Domainliste nur für HTTP-Anfragen einsetzen

Das Feld „Allowed HTTP Request Domains“ erscheint bei vielen Credentials für webbasierte APIs und Dienste. Wenn ein HTTP-Request-Node ein solches Credential verwendet, wählen Sie „Specific Domains“ und tragen die zulässigen Domains als kommagetrennte Liste ein. „All“ erlaubt die Verwendung für beliebige URLs in diesem Node; „None“ sperrt die Verwendung des Credentials im HTTP-Request-Node vollständig.

Prüfen Sie die tatsächlich verwendeten Nodes, bevor Sie der Liste eine Schutzwirkung für den gesamten Workflow zuschreiben. Ein dedizierter App-Node kann dasselbe Credential verwenden, ohne dass dessen Einstellung „Allowed HTTP Request Domains“ dort wirkt. Bei einem Ablauf mit HTTP-Request-Node und App-Node beschränkt die Liste somit nur den HTTP-Zweig.

Auch innerhalb einer erlaubten Domain unterscheidet die Einstellung nicht zwischen Lese- und Schreibaktionen der API. Für diese Grenze sind die Rechte des API-Schlüssels oder OAuth-Kontos beim jeweiligen Dienst maßgeblich. Halten Sie deshalb pro Verbindung fest, welche Ziel-Domains für HTTP-Anfragen vorgesehen sind und welche Berechtigungen das Konto selbst besitzt.

Workflow-Zugriff zusätzlich zur Credential-Freigabe prüfen

Die direkte Freigabe eines Credentials ist nicht der einzige Weg, auf dem jemand es nutzen kann. Die n8n-Regeln zur Workflow-Freigabe erlauben Workflow-Editoren, alle darin verwendeten Credentials zu nutzen, auch wenn diese nicht separat mit ihnen geteilt wurden. Ohne separate Credential-Freigabe können sie die betreffenden Nodes nicht bearbeiten; den Workflow können sie jedoch ansehen und ausführen.

Prüfen Sie deshalb neben der Sharing-Liste des Credentials auch den Workflow, der es bereits verwendet. Ein Workflow im persönlichen Bereich kann über „Share“ für ausgewählte Personen freigegeben werden. Liegt er in einem Projekt, ist er den Mitgliedern dieses Projekts zugänglich; zusätzliche Personen werden über die Projektmitgliedschaft eingebunden. Wer den Workflow ausführen kann, ist damit eine eigene Frage neben „Wer kann dieses Credential in einem neuen Workflow auswählen?“.

Das ist besonders wichtig, wenn eine feste Verbindung weitreichende Rechte beim Dienst besitzt. Die Person, die den Workflow ausführt, muss die geheimen Werte nicht kennen, um eine darin vorgesehene Aktion auszulösen. Beschränken Sie deshalb sowohl die Kontorechte beim Dienst als auch die Freigabe des Workflows auf dessen tatsächlichen Zweck.

Freigaben entziehen und Zuordnungen aktuell halten

Benötigt eine Person oder ein Projekt ein Credential nicht mehr, öffnen Sie dessen „Sharing“-Bereich, entfernen den entsprechenden Eintrag und speichern die Änderung. Prüfen Sie zugleich, ob weiterhin Zugriff auf einen Workflow besteht, der dieses Credential verwendet. Der Entzug der direkten Credential-Freigabe beantwortet wegen der Workflow-Rechte allein noch nicht, ob die Verbindung über einen bestehenden Ablauf nutzbar bleibt.

Für jeden produktiven Workflow reicht eine knappe Zuordnung: Welches Konto steht hinter dem Credential, ist die OAuth-Verbindung fest oder nutzerbezogen, wem gehören Credential und Workflow, wer kann den Ablauf ausführen und welche Nodes nutzen die Verbindung? Ergänzen Sie bei HTTP-Request-Nodes die erlaubten Domains. Bei dedizierten App-Nodes sind stattdessen die Rechte beim angebundenen Dienst und die Zugriffsrechte auf den Workflow die entscheidenden Stellschrauben.

Lesen Sie auch: