Automationen und KI-Agenten greifen häufig auf mehrere APIs zu. Die Wahl des Authentifizierungsverfahrens bestimmt, welche Identität ein System nachweisen kann, wie groß der Schaden eines gestohlenen Credentials ist und wie aufwendig Rotation oder Widerruf werden. Ein API-Key ist schnell eingerichtet, aber nicht automatisch für sensible oder benutzerbezogene Aktionen geeignet. OAuth 2.0 bietet mehr Steuerung, bringt jedoch einen komplexeren Token-Lebenszyklus mit.
Der n8n-Leitfaden vergleicht sieben verbreitete Ansätze: API-Keys, Basic Authentication, mTLS, HMAC, OAuth 2.0, JWT und OpenID Connect. Wichtig ist, dass diese Begriffe nicht dieselbe Ebene beschreiben. JWT ist ein Tokenformat, OAuth 2.0 ein Autorisierungsrahmen und OpenID Connect eine Identitätsschicht. Eine belastbare Architektur beginnt deshalb mit Akteur, Trust Boundary und erlaubter Wirkung, nicht mit einem bevorzugten Schlagwort.
Authentifizierung ist nicht Autorisierung
Authentifizierung bestätigt, wer oder was eine Anfrage stellt. Autorisierung entscheidet, was diese Identität tun darf. Ein technisch gültiges Token kann eine Anwendung eindeutig erkennen und zugleich viel zu breite Rechte besitzen. Für Automationen muss beides getrennt geprüft werden: Ist das Credential echt und aktuell? Und sind Scope, Ressource, Mandant, Aktion und Kontext für diesen Workflow zulässig?
Authentication verifies identity, while authorization decides what that identity is allowed to do.
n8n API Authentication Guide
n8n gibt an, konfigurierte Zugangsdaten verschlüsselt zu speichern und vom eigentlichen Workflow zu trennen. Das reduziert direkte Offenlegung im Flow, beseitigt aber nicht alle Risiken. Ein Workflow kann ein Credential weiterhin missbräuchlich verwenden, wenn das zugehörige Tool zu viele Aktionen erlaubt. Plattformzugriff, Backup, Schlüsselverwaltung, Exportmöglichkeiten und Logs bleiben Teil des Sicherheitsmodells.
Die sieben Verfahren nach Einsatzgebiet
API-Keys eignen sich für einfache Service-zu-Service-Integrationen, wenn Rechte eng und Rotation beherrschbar sind. Basic Authentication ist vor allem bei vertrauenswürdigen internen oder älteren Systemen anzutreffen; wiederverwendbare Zugangsdaten werden bei jeder Anfrage eingesetzt und verlangen durchgängiges TLS. Beide Varianten sind leicht zu implementieren, werden aber häufig zu langlebig, gemeinsam genutzt oder mit zu breiten Rechten versehen.
mTLS authentifiziert beide Verbindungsseiten über Zertifikate und passt zu kontrollierten Service-zu-Service-Beziehungen mit hohem Identitätsanspruch. Der Preis ist Zertifikatsbetrieb: Ausstellung, Verteilung, Erneuerung und Widerruf müssen zuverlässig funktionieren. HMAC signiert Anfragen mit einem gemeinsamen Geheimnis und schützt Integrität. Zusätzlich braucht es Zeitfenster oder Nonces gegen Replay-Angriffe sowie eine sichere Secret-Verteilung.
OAuth 2.0 ist für delegierten Nutzerzugriff oder kontrollierte Service-Identitäten geeignet. Scopes, kurze Laufzeiten und Refresh- oder Client-Credentials-Flows ermöglichen feinere Steuerung, erhöhen aber den Betriebsaufwand. JWT kann signierte, selbst enthaltene Claims transportieren und wird häufig mit OAuth kombiniert. Es ist kein eigenständiges Authentifizierungsprotokoll. Lange JWT-Laufzeiten erschweren vorzeitigen Widerruf; Claims, Signatur, Issuer, Audience und Zeit müssen pro Anfrage validiert werden.
OpenID Connect ergänzt OAuth 2.0 um standardisierte Nutzeridentität und Login. Es ersetzt keine API-Autorisierung. Ein ID Token ist nicht automatisch als Access Token für beliebige APIs geeignet. Unternehmen sollten Benutzeranmeldung, delegierte Rechte und Maschinenidentitäten als getrennte Pfade modellieren. Andernfalls landen menschliche Tokens in Hintergrundjobs oder technische Konten werden für interaktive Logins missbraucht.
- Einfache interne Integration: enger API-Key oder Basic Auth nur mit TLS, Rotation und minimalen Rechten.
- Starke Maschinenidentität: mTLS bei beherrschbarem Zertifikatslebenszyklus.
- Manipulationssichere Requests: HMAC mit Replay-Schutz und sauberer Zeitbasis.
- Delegierter Zugriff: OAuth 2.0 mit minimalen Scopes und kurzen Tokenlaufzeiten.
- Nutzerlogin: OpenID Connect für Identität, separate Autorisierung für API-Aktionen.
Entscheidung nach Trust Boundary und Schadensradius
Die richtige Wahl hängt davon ab, wer aufruft, wo das Credential gespeichert wird, wie die Verbindung geschützt ist und welchen Schaden ein Missbrauch auslösen kann. Ein interner Reporting-Job mit Leserechten hat andere Anforderungen als ein Agent, der Kundendaten ändern oder Zahlungen anstoßen kann. Je größer Wirkung und Reichweite, desto wichtiger werden kurze Laufzeiten, getrennte Identitäten, Transaktionsgrenzen und unabhängige Freigaben.
- Akteur, Datenklasse, Zielsystem und erlaubte Aktionen pro Workflow dokumentieren.
- Engstes unterstütztes Verfahren und minimale Scopes beziehungsweise Rollen auswählen.
- Speicherung, Rotation, Ablauf, Widerruf und Notfallentzug als Lebenszyklus testen.
- Ungültige Signaturen, falsche Audience, Replay, abgelaufene Tokens und Rechteüberschreitung negativ prüfen.
- Nutzung, Fehler, ungewöhnliche Volumina und Änderungen an Credentials revisionsfähig überwachen.
Credential-Lebenszyklus im Betrieb
Durchgängiges TLS ist für alle genannten Verfahren eine Basis. Darüber hinaus braucht jedes Credential einen Owner, Zweck, Ablauf oder Rotationsplan. Gemeinsame Schlüssel über viele Workflows vergrößern den Schadensradius und erschweren Zuordnung. Getrennte Dienstidentitäten pro Prozess oder Risikoklasse verbessern Audit und Entzug. Secrets dürfen nicht in Prompts, Workflowdaten, Tickets oder Debug-Logs gelangen.
Monitoring sollte nicht nur fehlgeschlagene Logins zählen. Relevant sind neue Scopes, ungewöhnliche Zielressourcen, Nutzung außerhalb typischer Zeiten, häufige Refreshes und Credentials ohne Owner. Rotation muss unter Last getestet werden, damit alte und neue Schlüssel während einer kontrollierten Übergangsphase funktionieren. Der Notfallentzug braucht einen bekannten Ersatzpfad, sonst bleiben kompromittierte Credentials aus Angst vor Betriebsunterbrechung aktiv.
Fazit
Es gibt kein universell bestes Verfahren für jede Automation. API-Keys und Basic Auth sind einfach, mTLS und HMAC stärken Maschinenkommunikation, OAuth 2.0 steuert delegierte Rechte, JWT transportiert Claims und OpenID Connect standardisiert Nutzeridentität. Unternehmen sollten diese Ebenen nicht vermischen. Entscheidend sind minimale Autorisierung, sichere Speicherung, kurze Gültigkeit, getesteter Widerruf und Audit pro Workflow. Die Methode ist nur so stark wie ihr kompletter Credential-Lebenszyklus.