Begriff
Credentials (n8n)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Credentials sind der Schlüsselbund von n8n. Wenn du mit anderen Apps sprechen willst (Gmail, Slack, OpenAI), brauchst du einen Ausweis. Du willst nicht bei jedem Node dein Passwort neu eintippen. Das wäre unsicher und nervig. Stattdessen speicherst du deine Schlüssel einmal zentral im Tresor ("Credentials Area"). Die Nodes greifen dann nur darauf zu: "Benutze den Schlüssel 'Gmail Privat'".
Merksatz: Der sichere Ort, an dem n8n deine Passwörter und API-Keys verschlüsselt aufbewahrt.
Lernbruecke für Anfänger
Wenn du bei Credentials (n8n) ganz neu startest, denke zuerst nicht an Fachwörter, sondern an die Alltagssituation: Secrets, Tokens und API-Keys verwalten. Der Begriff beschreibt einen klaren Baustein im größeren Ablauf. Frage dich immer: Was ist der Eingang, was passiert in der Mitte, und woran erkenne ich am Ende, dass es funktioniert hat?
Ein guter Einstieg ist, den Begriff in einem Satz zu erklären, danach ein reales Beispiel zu nennen und erst dann die Technikdetails zu lernen. So entsteht kein reines Auswendiglernen, sondern ein mentales Modell.
Das Anlegen ist meist Schritt 1 beim Bauen eines Workflows.
- Typ wählen: "Google OAuth2", "Slack API Token", "MySQL Password".
- Daten eingeben: Kopiere den Key von der anderen Plattform hier rein.
- Name vergeben: Gib ihm einen sprechenden Namen! Nicht "Account 1", sondern "Gmail (Max Privat)" oder "OpenAI (Firma)".
Sicherheit beim Teilen
Wenn du einen Workflow exportierst (JSON), werden die Credentials automatisch entfernt. Das heißt: Du kannst deinen genialen Workflow gefahrlos an einen Freund schicken. Dein Passwort steht nicht drin. Er muss bei sich seine eigenen Credentials eintragen.
1. Verschlüsselung (Database)
n8n speichert Credentials in seiner internen Datenbank (SQLite/Postgres).
Dabei werden sie mit einem Encryption Key verschlüsselt.
Dieser Key wird beim ersten Start von n8n generiert und in der Datei .n8n/config gespeichert.
Wichtig: Wenn du diesen Key verlierst (oder den Docker-Container löschst ohne Volume), sind alle Passwörter in der Datenbank nutzloser Müll. Backup ist Pflicht!
2. Environment Variables vs. Credentials
Manche Geheimnisse (wie Datenbank-Passwörter für n8n selbst) gehören in Environment Variables (Docker-Ebene).
API-Schlüssel für externe Apps gehören in Credentials (App-Ebene).
Du kannst aber auch beides mischen: Du kannst in einem Credential-Feld {{ $env.MY_SECRET_KEY }} verwenden, um den Wert dynamisch aus der Umgebung zu laden.
3. OAuth2 Renewals
Bei OAuth2 (z. B. Google Login) laufen Tokens nach 1 Stunde ab. n8n kümmert sich automatisch um die Erneuerung (Refresh Token). Du musst dich einmal einloggen, und n8n bleibt monatelang eingeloggt, solange der Refresh Token gültig ist.
External Secrets Management (HashiCorp Vault)
In Enterprise-Deployments ist es verpönt, API-Keys überhaupt in der lokalen SQLite/Postgres-Datenbank von n8n (oder irgendeiner anderen App) ruhen zu lassen. Die Evolution des Credential-Managements ist die Integration mit External Secret Stores (wie AWS Secrets Manager oder HashiCorp Vault). Anstatt den Stripe-Key in n8n zu pasten, injected man in n8n einen Pointer. Zur Laufzeit (Execution) authentifiziert sich der n8n-Pod beim Vault, zieht den Schlüssel ephemer (flüchtig) in den RAM, nutzt den Secret-Wert für den API-Call und verwirft ihn danach wieder. Wenn ein Admin den Stripe-Key rotieren (ändern) muss, ändert er ihn im zentralen Vault — n8n nutzt beim nächsten Lauf natlos den neuen Key, ohne dass ein Bot-Konfigurator Hand anlegen muss.
Encryption am Ruhestrom (Encryption at Rest / KMS)
Die n8n-encryption stützt sich lokal auf eine .env generierte Phrase (N8N_ENCRYPTION_KEY). Der Algorithmus nutzt oft AES-256 GCM (Galois/Counter Mode).
Sollte die Datenbank-Snapshots von AWS RDS auf GitHub leaken, blockt die Verschlüsselung den Zugriff. Leakt aber gleichzeitig die .env Config-File aus dem Helm-Chart, ist die Abwehrkraft futsch.
Die absolute Profilösung ist KMS (Key Management Service). n8n verwebt seine Verschlüsselung mit einem Hardware Security Module (HSM) von AWS/GCP. Die Keys werden durch das Modul automatisch generiert, aufgeteilt und verwaltet; niemand, noch nicht mal der Server-Root, kann den "Master-Entschlüsselungs-Key" im Klartext exportieren.
RBAC (Role-Based Access Control) für Credentials
Wenn du 50 Workflows und 10 Devs im n8n hast, willst du nicht, dass "Praktikant Tom" versehentlich auf die Credentials für den Produktions-MySQL-Cluster ("Root Access") zugreifen und sie im SQL-Node nutzen kann. Modernes n8n-Setup ab Enterprise-Stufe verlangt striktes RBAC. Credentials werden Workspaces oder User-Groups ("Ops-Team") zugeordnet. Tom sieht im Dropdown für den API-Node nur die "Staging_DB" Credentials. Der Workflow, der die Prod-DB triggert, verwehrt Tom jegliche Ausführung oder Modifikation, weil sein User-Account den verschlüsselten Trust-Context der Prod-Credentials nicht aufbrechen darf.
Quick-Check
Was passiert mit deinen Passwörtern, wenn du einen Workflow per JSON an einen Kollegen schickst?
Nichts. Sie werden nicht mitexportiert. Der Kollege muss seine eigenen Credentials eintragen.Warum sind Credentials sicherer, als das Passwort direkt in den Node zu schreiben?
Weil sie zentral verschlüsselt gespeichert werden und beim Export nicht versehentlich geleakt werden können.Was passiert, wenn du den Encryption Key von n8n verlierst?
Du kannst deine gespeicherten Credentials nicht mehr entschlüsseln. Du musst alle neu eingeben.