Ich richte Workflows für mehrere verschiedene Benutzer ein. Wie kann ich Anmeldedaten für jeden von ihnen einrichten, ohne ihre persönlichen Konten zu erhalten, oder können sie diese selbst erstellen?
Wenn du eine Version von n8n mit aktiviertem User Management verwendest (verfügbar in n8n Cloud und den meisten selbstgehosteten Installationen), ist der Prozess unkompliziert:
- Benutzer einladen: Du lädst die Benutzer per E-Mail zu deiner n8n-Instanz ein.
- Private Credentials: Sobald sie sich anmelden, sind alle Credentials, die sie erstellen, standardmäßig privat für sie.
- Workflow-Ausführung: Wenn du einen Workflow für sie erstellst, kannst du das Credential-Feld leer lassen oder einen Platzhalter setzen. Wenn der Benutzer den Workflow öffnet, wählt er einfach sein vorkonfiguriertes Credential aus dem Dropdown-Menü aus.
Für Services, die OAuth2 unterstützen (wie Google, Slack, Microsoft usw.), muss der Benutzer dir sein Passwort nie geben:
- Du richtest die „App
Es hängt davon ab, welche Art von Anmeldedaten du einrichtest.
Für gemeinsame Dienste (einen Slack-Bot, eine Datenbankverbindung, eine interne API, alles, wo ein Konto das ganze Team bedient): Du kannst die Anmeldedaten selbst erstellen, dann öffnen und auf die Registerkarte Sharing klicken. Es gibt ein Dropdown-Menü, um sie mit bestimmten Benutzern oder Projekten zu teilen. Sie können sie in Workflows verwenden, sehen aber nicht den eigentlichen API-Schlüssel oder das Geheimnis. Es bleibt für dich als Inhaber gesperrt.
Für persönliche OAuth-Konten (Gmails, Google Drive, Notion usw. jeder einzelnen Person): Da führt kein Weg daran vorbei. Jeder Benutzer muss sich mit seinem eigenen Konto authentifizieren. Du kannst das nicht für ihn tun, ohne dich als er anzumelden. Die gute Nachricht: Der Prozess ist für ihn genauso wie für dich: Credentials → Add Credential → Service auswählen → OAuth-Flow durchlaufen. Solange sie ein n8n-Konto auf deiner Instanz haben, können sie das selbst machen.
Praktisch also: Du richtest gemeinsame Service-Anmeldedaten ein und teilst sie aus, deine Teamkollegen erstellen ihre eigenen für alles, das an ihre persönlichen Konten gebunden ist.
Eine kleine Sache, die es wert ist zu wissen: Benutzer, mit denen du Anmeldedaten teilst, können die Anmeldedaten in Workflows verwenden, können aber das zugrunde liegende Geheimnis nicht einsehen oder bearbeiten. Wenn ihr Token abläuft oder aus irgendeinem Grund nicht funktioniert, entweder teilst du eine neue Version oder sie müssen sich selbst neu authentifizieren. Es lohnt sich, diese Erwartung von vornherein festzulegen.
Hi! Ich bin auf diesen Thread gestoßen, weil meine eigene Diskussion über Credential HUB unter den verwandten Themen verlinkt war.
Nach dem Lesen deines Use Cases denke ich, dass du möglicherweise auf eines der Probleme stößt, für das Credential HUB entwickelt wurde: zentrale Verwaltung von Anmeldedaten, kontrollierter Zugriff für Workflows, Lebenszyklusmanagement und Rotation von Anmeldedaten, Zustandsüberwachung und eine konsistente API für Automatisierungsplattformen.
Es kann die richtige Lösung für dein Setup sein oder auch nicht, aber falls dich das interessiert, hier ist ein Überblick über das Projekt und was es zu lösen anstrebt:
Ich würde mich wirklich über Feedback oder Gedanken von Menschen freuen, die mit ähnlichen Herausforderungen umgehen.
Luis
Hallo @Bobby_Cheung
Ja, sie können ihre eigenen erstellen — und sollten es normalerweise auch.
Wichtiger Punkt: Du benötigst ihr Passwort nie. Bei OAuth-Diensten (Google, Slack, Microsoft) konfigurierst du die App einmal und sie klicken auf Verbinden und autorisieren ihr eigenes Konto.
1. Lade sie zu deiner Instanz ein. Sie erstellen die Anmeldedaten und teilen sie in ein Projekt. Du kannst sie verwenden, aber kannst das Geheimnis nicht anzeigen oder bearbeiten. Funktioniert auf allen Cloud-Plänen.
Das Teilen eines Workflows umgeht dies — Editoren erhalten Zugriff auf alle darin enthaltenen Anmeldedaten.
2. Anmeldedaten für Endbenutzer (Enterprise, Vorschau). Eine Anmeldedatenvorlage, jeder Benutzer verbindet sein eigenes Konto. Ausführungen verwenden denjenigen, der sie ausgelöst hat.
Nur OAuth und manuelle/Chat Hub/MCP-Trigger — nicht geplant oder Webhook.
3. Separate Instanz pro Client. Sie besitzen das Konto und laden dich ein. Saubere Grenze, einfache Übergabe. Nachteil: Wechsel zwischen Instanzen.
4. Dienstkonten (nur Google). Client teilt nur das spezifische Blatt oder den Ordner mit der E-Mail des Dienstkontos. Keine persönlichen Konten beteiligt.