n8n Connection (Credential)

1. Neuen Node hinzufügen (z. B. "Google Sheets").
2. Dropdown "Credential to connect with".
3. "Create New".
4. Wähle Typ: "Google OAuth2 API".
5. Achtung: Du musst oft in der Google Cloud Console erst eine "App" anlegen, um Client-ID und Secret zu bekommen. (n8n hilft mit Dokus).
6. Nach dem Verbinden ("Sign in with Google") ist die Connection grün ("Verified").

Praxisroutine

In der Praxis lernst du n8n Connection (Credential), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Encryption Key

n8n verschlüsselt Credentials in der SQLite/Postgres DB. Der Schlüssel liegt in ~/.n8n/config oder wird per Environment Variable N8N_ENCRYPTION_KEY gesetzt. Wichtig: Wenn du n8n auf einen neuen Server umziehst und diesen Key vergisst, sind alle Credentials unbrauchbar. Du musst alles neu eingeben. Backup des Encryption Keys ist Pflicht!

2. Scoped Credentials

Besonders bei OAuth2: Du willst nicht "Vollzugriff auf Google Drive" geben, wenn du nur eine Datei lesen willst. In der Connection-Config kannst du Scopes definieren. drive.readonly, gmail.send. Best Practice (Least Privilege): Erstelle für jeden Zweck eine eigene Connection mit minimalen Scopes.

3. External Secrets (Enterprise)

In großen Firmen willst du Secrets nicht in der n8n-Datenbank haben. Sie liegen im Vault (HashiCorp Vault, AWS Secrets Manager). Die n8n Enterprise Edition erlaubt es, Credentials dynamisch aus dem Vault zu laden, statt sie statisch zu speichern.

1. SQLite Encryption und AES-256

Unter der Haube ist ein "Credential" in n8n ein roher JSON-Payload in der Base-Tabelle credentials_entity. Der kritische Pfad: Die data Column ist nicht Plaintext, sondern AES-256-GCM verschlüsselt. Den Schlüssel generiert n8n bei der Erst-Installation ("Encryption Key") und salzt davon den Master-Key. Das Resultat ist eine massive Security-Falle: Ein Backup via simpler SQL-Dump-Kopie nützt nichts, falls man den Server ohne die exakte ~/.n8n/encryption File migriert. Der Backend-Node-Prozess wird beim Neustart stumm abstürzen ("Bad Decrypt"), weil sämtliche Keys in der Datenbank an den fehlenden Initialschlüssel gebunden waren. Die strikte Trennung von Data und Key schützt vor Angriffen trên DB, erfordert aber komplexes Key-Management.

2. OAuth2 Callback Architektur

Wenn eine Gmail Connection initiiert wird, passiert extrem viel. n8n öffnet die Consent-Page von Google in einem Pop-up. Der n8n Backend-Server baut derweil einen asynchronen Listener-State mit dem Parameter state (CSRF Protection) auf einen speziellen public Endpoint am n8n-Server auf (/rest/oauth2-credential/callback). Du loggst dich bei Google ein, bewilligst "n8n", und Google zwingt deinen Browser per HTTP 302 Redirect genau in diese /rest/oauth2.. URL deines n8n Servers, vollbepackt mit dem hart erarbeiteten authorization_code. Der n8n Node verifiziert sofort den State und ruft im Hintergrund nochmalig Google API Server auf, tauscht den Code in Access- und Refresh-Token (token_exchange) um und spert es final verschlüsselt ins Credential. Dieser empfindliche Flow bricht immer, wenn n8n hinter einem Reverse Proxy (nginx) betrieben wird und die Webhooks URLs (BaseURL config in .env) falsch genatet wurden (Google sendet den Code dann oft fatalerweise an localhost:5678 zurück).

3. Credential Injection / Dynamic Bindings

Ein fortgeschrittenes Feature in Enterprise-Automatisierung. Was, wenn ein Workflow an 5 Mandanten ausgerollt wird und in Abhängigkeit vom Mandanten (Payload msg.tenantId) unterschiedliche Shopify-Credentials nutzen muss? In n8n können Credentials via Expression Mode injiziert werden ({{ $json.tenantShopifyId }}). Der Workflow wird am Load-Balancer abgefeuert, analysiert den Payload, holt sich durch Lookup oder Variables den korrekten Key-Pointer und spannt zur Laufzeit des Nodes dynamisch die Binding-Brücke ins Credential-Subsystem auf. So betreibt man massive Multi-Tenant-Strukturen, ohne den Workflow 5 Mal kopieren zu müssen.