# 09 — Credentials & Auth

> Die meisten n8n-Probleme im Produktionsbetrieb sind Auth-Probleme.
> Nicht weil Auth schwer ist — sondern weil man es falsch aufbaut.

---

## Das Credential-System

n8n hat ein eingebautes Credential-Management. Du gibst API-Keys, OAuth-Tokens und Passwörter einmal ein — verschlüsselt gespeichert — und referenzierst sie dann in Nodes.

**Goldene Regel: Niemals API-Keys direkt in Nodes eingeben oder in Expressions hardcoden.**

Warum: Credentials in Nodes landen im Workflow-JSON. Das Workflow-JSON landet in Backups, Exports, Git-Repos. API-Keys in Git-Repos sind ein klassisches Sicherheitsproblem.

---

## Auth-Typen

### API Key
Der einfachste Typ. Ein statischer String, der als Header oder Query-Parameter mitgesendet wird.

```
Header: Authorization: Bearer sk-abc123...
// oder
Query: ?api_key=sk-abc123...
```

Im HTTP Request Node: "Authentication" Tab → "Header Auth" oder "Query Auth" → Credential auswählen.

API-Keys laufen nicht automatisch ab — aber sie können manuell rotiert werden. Wenn ein Dienst den Key rotiert, müssen alle Workflows aktualisiert werden, die ihn nutzen.

### OAuth 2.0
Für APIs von Google, Microsoft, Slack, etc. Token wird automatisch erneuert.

n8n übernimmt den OAuth-Flow: Du autorisierst einmalig → n8n speichert Access Token + Refresh Token → erneuert automatisch wenn der Token abläuft.

**Häufiges Problem:** OAuth-Token läuft ab und die automatische Erneuerung schlägt fehl (z.B. wenn der Nutzer die App-Berechtigung widerrufen hat). Symptom: `401 Unauthorized` nach wochen- oder monatelangem Funktionieren. Lösung: Credential neu autorisieren.

### HTTP Basic Auth
Username + Passwort, Base64-kodiert im Authorization-Header. Für ältere APIs.

### n8n-native Credentials (für integrierte Nodes)
Nodes für Slack, GitHub, Airtable etc. haben eigene Credential-Typen. Sie wissen welche Felder nötig sind und validieren sie beim Speichern.

---

## Webhook Auth: Der meistunterschätzte Teil

Webhooks empfangen Daten von außen. Ohne Auth kann jeder deinen Webhook aufrufen.

n8n bietet für den Webhook-Node mehrere Absicherungsoptionen:

### Header Auth
Erwarteter Header muss im Request vorhanden sein:
```
X-Webhook-Secret: geheimes-token-hier
```

### Basic Auth
Username/Passwort müssen im Authorization-Header stimmen.

### JWT
JSON Web Token wird validiert.

Für interne Workflows (nur du rufst sie auf): Header Auth mit einem starken zufälligen Token.  
Für externe Dienste (Stripe, GitHub Webhooks): Die meisten Dienste senden eine Signatur — prüfe sie im Code-Node nach dem Webhook.

---

## HTTPS-Pflicht für Webhooks

n8n Cloud-Instanzen haben automatisch HTTPS.  
Self-hosted n8n **muss** hinter einem Reverse Proxy (nginx, Traefik, Caddy) mit gültigem SSL-Zertifikat betrieben werden.

Warum: Die meisten externen Dienste (Stripe, GitHub, Shopify) erlauben nur HTTPS-Webhook-URLs. Ein `http://`-Webhook wird abgelehnt.

Lokal entwickeln: Nutze [ngrok](https://ngrok.com) oder [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) um deinen lokalen Port temporär unter einer HTTPS-URL erreichbar zu machen.

---

## Credential-Scope: Wer kann was

In n8n können Credentials:
- **Privat** sein: Nur der Ersteller kann sie nutzen
- **Geteilt** sein: Bestimmte Nutzer oder alle im Workspace

In Team-Umgebungen: Shared Credentials für geteilte Services (z.B. eine zentrale Slack-Integration), private Credentials für persönliche API-Keys.

---

## Credential-Testing

Wenn du eine Credential erstellst, bietet n8n meist einen "Test" Button. Nutze ihn.  
Ein gespeichertes Credential ist kein bewiesenes Credential.

**Kritischer Unterschied: Test ≠ Produktionsverhalten**

Der Test-Button prüft Erreichbarkeit — nicht Berechtigungsumfang. Zwei häufige Fallen:

**OAuth-Scope-Problem:** Die Verbindung zu Google funktioniert, aber dein Workflow braucht `drive.file`-Zugriff, der Token hat nur `drive.readonly`. Der Test ist grün. Der Workflow schlägt in Produktion fehl.  
Lösung: Beim Autorisieren genau prüfen welche Scopes angefordert werden — nicht erst wenn der Fehler kommt.

**"No testing function found":** Manche Credential-Typen (insbesondere Custom Credentials und ältere Integrationen) haben keine Test-Funktion. n8n speichert sie ohne Validierung. Das einzige Mittel ist ein echter Node-Testlauf.

Fazit: Credential-Tests geben Vertrauen in die Verbindung. Das Vertrauen in die Berechtigung kommt nur durch einen echten Testlauf mit echten Daten.

---

## Produktions-Checkliste

- [ ] Alle API-Keys als Credentials gespeichert, nicht hardcoded
- [ ] OAuth-Tokens getestet und autorisiert
- [ ] Webhooks mit Auth abgesichert
- [ ] HTTPS für alle Webhook-Endpunkte bestätigt
- [ ] Error Workflow für 401-Fehler aufgesetzt (→ [Seite 08](08-error-handling.md))

---

**Nächste Seite:** [10 — Webhooks & Trigger](10-webhooks.md)