Connection (Credential)

Damit n8n (oder irgendein Tool) auf deine Daten zugreifen kann (z.B. deine E-Mails lesen), braucht es eine Erlaubnis. Eine Connection (in n8n "Credential" genannt) ist wie der Schlüsselbund. Dort speicherst du sicher deine Passwörter oder API-Keys für Dienste wie Google, Slack oder OpenAI.

:level0

Lernbruecke: Eine Connection ist die Verbindung zu einem anderen Dienst. Zugangsdaten beweisen, dass du hinein darfst; Berechtigungen legen fest, was du dort tun darfst.

Lernbruecke für Anfänger

Wenn du bei Connection (Credential) ganz neu startest, denke zuerst nicht an Fachwörter, sondern an die Alltagssituation: Dienste verbinden und Berechtigungen verstehen. 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.

Du erstellst eine Connection einmal zentral und kannst sie dann in vielen verschiedenen Workflows benutzen. Typische Methoden:

API Key: Ein langes Passwort ("sk-....").
OAuth2: Der moderne Standard ("Mit Google anmelden"). Du wirst zu Google weitergeleitet, klickst "Erlauben", und n8n bekommt einen Token.

Wichtig: Gib deine Credentials niemals weiter! In n8n sind sie verschlüsselt gespeichert.

:level1

Praxisbeispiel: Du verbindest Gmail. Der richtige Account, die passenden Rechte und ein gueltiger Token sind wichtiger als der Node selbst. Wenn der falsche Account verbunden ist, arbeitet der Workflow fachlich falsch.

Credentials sind vom Workflow getrennt. Wenn du einen Workflow exportierst (als JSON), sind die Credentials nicht enthalten (nur die ID/Name). Das ist ein Sicherheitsfeature, damit du Workflows teilen kannst, ohne deine Passwörter zu leaken. Der Empfänger muss seine eigenen Credentials für den Dienst hinterlegen.

:level2

Technisch sind Connections oft API-Keys, OAuth-Tokens oder Sessiondaten. Gute Setups geben nur minimale Rechte, erneuern Tokens kontrolliert und dokumentieren, wofür jede Verbindung genutzt wird.

Technische Einordnung im System

Technisch ist Connection (Credential) nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. Encryption at Rest & Key Derivation

n8n verschlüsselt Credentials in der Datenbank (PostgreSQL oder SQLite) standardmäßig. Das passiert per AES-256-GCM. Der Master-Entschlüsselungs-Key (N8N_ENCRYPTION_KEY) wird jedoch nicht direkt genutzt, sondern dient oft als Input für eine Key-Derivation-Function (z.B. HKDF oder PBKDF2), um kryptografisch stärkere Schlüssel zur Laufzeit abzuleiten. Liegt der Key lokal im Dateisystem (~/.n8n/config) und verliert man ihn bei einer Server-Migration, sind aus Sicherheitsgründen alle migrierten Credentials wertloser kryptografischer Müll. Man verliert totalen Zugriff (Cryptoshredding).

2. OAuth2 Authorization Code Flow

Bei OAuth2 fungiert n8n in der Cloud Architektur als Client Application (Relying Party).

Authorization Request: Du wirst zum Authorization Server (z.B. accounts.google.com) geleitet.
Consent: Du erlaubst spezifischen Zugriff in Form eines festgelegten Scopes (z.B. gmail.readonly).
Callback: Google ruft die Redirect URI der n8n-Instanz auf (z.B. /rest/oauth2-credential/callback) und übergibt einen kurzlebigen Authorization Code.
Token Exchange: Backend zu Backend (unsichtbar) tauscht n8n diesen Code gegen ein Access Token (valid für ~1h) und ein kryptografisches Refresh Token (langlebig).
Auto-Refresh Lifecycle: Bevor ein API Call scheitert, nutzt n8n automatisch das Refresh Token, um ein neues Access Token zu beantragen.

3. API Key Injection via HTTP Headers

Die primitivste, aber verbreitetste Methode neben OAuth. Im n8n Backend wird ein statischer Token (API-Key) in C++ oder Node.js einfach in jeden ausgehenden HTTP-Application Layer (OSI Layer 7) Request Request injiziert. Entweder im Header Authorization: Bearer <token> oder seltener als Query Parameter (?api_key=xyz). Weil Header verschlüsselt durch TLS (Transport Layer Security) über das Netzwerk wandern, sind API-Keys sicher gegen Sniffing in fremden WLANs (Man-In-The-Middle), solange HTTPS strikt (HSTS) erzwungen wird.