OAuth, API-Key und Service Account: Authentifizierung für Automationen

Ein Kunde bringt einen n8n-Workflow mit, der jede Nacht Bestellungen aus dem Shopsystem abruft. Beim Blick in die Credentials liegt dort ein API-Key, angelegt vor zwei Jahren von einem Mitarbeiter, der die Firma inzwischen verlassen hat. Niemand weiß mehr, welche Rechte der Key hat, ob er noch gebraucht wird oder wo er außer in diesem einen Workflow noch verwendet wird. Das ist kein Einzelfall, sondern der Normalzustand in vielen KMU, die mit n8n, Power Automate, Make oder Zapier automatisieren: Zugangsdaten werden angelegt, wenn ein Workflow sie braucht, und bleiben liegen, wenn sie nicht mehr gebraucht werden.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die Automationen betreiben oder aufsetzen und wissen wollen, welche Authentifizierungsmethode wann passt — ohne Softwareentwickler:in zu sein. Er beantwortet die praktische Frage: API-Key, OAuth oder Service Account — was setze ich für welchen Workflow ein, und wie sichere ich es ab?

Begriffe kurz geklärt

Drei Begriffe, die häufig durcheinandergeworfen werden, obwohl sie unterschiedliche Probleme lösen:

• API-Key ist eine einzelne Zeichenkette, die ein System als Berechtigungsnachweis akzeptiert. Kein Bezug zu einer Person, keine eingebaute Ablaufzeit in den meisten Implementierungen, keine automatische Einschränkung auf bestimmte Aktionen.
• OAuth 2.0 ist ein Autorisierungsprotokoll: eine Person oder ein System erteilt einer Anwendung begrenzte, widerrufbare Rechte (Scopes), ohne das eigentliche Passwort weiterzugeben. Das Ergebnis ist ein kurzlebiges Zugriffstoken, das automatisch erneuert wird.
• Service Account ist eine Identität für Maschinen statt für Menschen — ein eigenes „Konto”, das ein System im Namen einer Automation nutzt, meist über einen Schlüssel (Key) oder über ein Verfahren, das ganz ohne gespeicherten Schlüssel auskommt.

Alle drei sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Situationen. Die Frage ist selten „API-Key oder OAuth”, sondern: Wer oder was greift hier zu, wie lange, und mit welchen Rechten?

Was ist ein API-Key?

Ein API-Key ist im Kern ein Passwort ohne Benutzernamen. Du erzeugst ihn im Verwaltungsbereich des Zielsystems, kopierst ihn in dein Automatisierungstool und schickst ihn bei jeder Anfrage mit — meist im HTTP-Header, seltener als Teil der URL. Das Zielsystem prüft nur: Ist dieser Key gültig? Es prüft in der Regel nicht, wer den Key gerade verwendet.

Das macht API-Keys attraktiv für die Einrichtung: keine Weiterleitung durch einen Login-Bildschirm, keine Rückfrage, kein Warten auf eine Freigabe. Viele einfache APIs — Wetterdaten, Übersetzungsdienste, viele SaaS-Tools mit schlankem Funktionsumfang — bieten ausschließlich API-Keys an, weil der Implementierungsaufwand für den Anbieter gering ist.

Der Nachteil liegt in genau dieser Einfachheit. Ein API-Key ist ein Generalschlüssel: Wer ihn besitzt, hat in der Regel alle Rechte, die der Key mitbringt, unabhängig davon, ob derjenige eigentlich zugreifen dürfte. Es gibt normalerweise keine eingebaute Ablaufzeit, keinen automatischen Widerruf und keine differenzierte Rechtevergabe auf Aktionsebene. Landet ein API-Key in einem öffentlichen Repository, einer Slack-Nachricht oder einer weitergeleiteten E-Mail, bleibt er gültig, bis ihn jemand aktiv widerruft — und das setzt voraus, dass überhaupt jemand bemerkt, dass er kompromittiert wurde.

Wie funktioniert OAuth?

OAuth 2.0 löst genau das Problem, das API-Keys offenlassen: Es trennt „wer bin ich” von „was darf ich” und macht Zugriff zeitlich begrenzt und widerrufbar, ohne dass ein Passwort die Anwendung erreicht. Nach der Dokumentation von Make.com läuft ein OAuth-2.0-Verbindungsaufbau in einer festen Reihenfolge ab: Zuerst leitet der Dienst zur Autorisierungsseite des Zielsystems weiter (authorize), dort meldet sich die Person an und erteilt bestimmte Rechte — sogenannte Scopes, etwa „Kalender lesen”, aber nicht „Kalender löschen”. Das Zielsystem gibt daraufhin einen Autorisierungscode zurück, den der Dienst gegen ein Zugriffstoken und ein Refresh-Token eintauscht (token). Das Zugriffstoken ist meist nur kurz gültig; läuft es ab, holt sich die Automation über das Refresh-Token automatisch ein neues (refresh), ohne dass die Person sich erneut anmelden muss.

Microsoft beschreibt für Power-Automate-Flows mit HTTP-Trigger einen ähnlichen Grundgedanken auf der Empfängerseite: Ein Flow lässt sich so konfigurieren, dass nur authentifizierte Aufrufe aus dem eigenen Tenant akzeptiert werden, geprüft anhand von Claims im mitgeschickten Token — etwa Aussteller, Tenant-ID und Objekt-ID der aufrufenden Identität. Das zeigt den zweiten Vorteil von OAuth gegenüber reinen API-Keys: Der Zugriff lässt sich nicht nur zeitlich begrenzen, sondern auch an eine überprüfbare Identität und einen definierten Geltungsbereich (Audience) binden.

Für dich als Anwender:in bedeutet das: OAuth ist aufwändiger einzurichten (Registrierung der Anwendung beim Anbieter, Client-ID und Client-Secret, oft ein Freigabebildschirm), bietet dafür aber genau die Kontrollen, die API-Keys fehlen — Scopes statt Alles-oder-nichts, automatischer Tokenwechsel statt statischer Zeichenkette, und einen Widerruf, der sofort greift, weil das System weiß, welche Sitzung zu welcher Person gehört.

Wann braucht man einen Service Account?

OAuth setzt in seiner klassischen Form eine Person voraus, die sich anmeldet und Rechte erteilt. Genau das passt nicht zu jedem Workflow: Ein nächtlicher Datenabgleich, ein Server-zu-Server-Prozess oder eine Automation, die weiterlaufen soll, auch wenn niemand gerade am Rechner sitzt, braucht eine Identität, die nicht an eine einzelne Person gebunden ist. Dafür gibt es Service Accounts.

Ein Service Account ist ein eigenes Konto für eine Anwendung oder einen Workflow, kein Konto für einen Menschen. Am Beispiel von Google zeigt sich das praktische Vorgehen: In der n8n-Dokumentation wird beschrieben, dass ein Google Service Account über eine JSON-Schlüsseldatei eingerichtet wird, aus der die E-Mail-Adresse des Service Accounts (client_email) und ein privater Schlüssel (private_key) in die Zugangsdaten von n8n übertragen werden. Diese Schlüsseldatei ersetzt Login und Passwort vollständig — das Service-Account-Konto „meldet sich” nie interaktiv an.

Zwei Punkte gehören zur ehrlichen Einordnung dazu:

Erstens: Service Accounts sind mächtig, aber nicht automatisch sicherer als API-Keys. Der Schlüssel eines Service Accounts ist im Kern ebenfalls eine statische Zeichenkette (ein privater Schlüssel), die dieselben Risiken trägt wie ein API-Key, wenn sie in falsche Hände gerät — nur mit potenziell größerer Reichweite, weil Service Accounts oft mehr Rechte haben als ein einzelner API-Key. Google Cloud rät deshalb ausdrücklich, Service-Account-Schlüssel als Ausnahme zu behandeln und, wo verfügbar, sicherere Alternativen zu nutzen — etwa an eine Rechenressource gebundene Service Accounts oder föderierte Identitäten, bei denen gar kein herunterladbarer Schlüssel entsteht.

Zweitens: Zugriffsrechte müssen bei Service Accounts explizit vergeben werden. Ein neu angelegter Google Service Account sieht laut n8n-Dokumentation zunächst gar nichts — Ressourcen wie Dateien in Google Drive müssen aktiv mit der E-Mail-Adresse des Service Accounts geteilt werden, bevor ein Zugriff möglich ist (und seit April 2025 haben neu angelegte Service Accounts keinen Zugriff mehr auf „Meine Ablage”, nur noch auf geteilte Ablagen). Das ist mehr Aufwand als ein einzelner Freigabe-Klick bei OAuth, sorgt aber auch für eine bewusstere, dokumentierte Rechtevergabe.

Wie speichert man Secrets?

Unabhängig davon, ob API-Key, OAuth-Client-Secret oder Service-Account-Schlüssel: Der Speicherort entscheidet über einen Großteil des Risikos. Der OWASP Secrets Management Cheat Sheet formuliert die Grundregel unmissverständlich — Secrets gehören nicht als Klartext in Quellcode, Konfigurationsdateien oder geteilte Dokumente, weil genau dort sie am häufigsten unbeabsichtigt landen und am längsten unentdeckt bleiben.

Praktisch heißt das für den KMU-Alltag:

• Nutze den eingebauten Credential-Speicher deines Automatisierungstools. n8n, Power Automate und Make verschlüsseln hinterlegte Zugangsdaten und trennen sie von der sichtbaren Workflow-Konfiguration — anders, als wenn ein Key direkt in einem HTTP-Request-Node oder einer Formel steht.
• Trenne Produktiv- von Testzugängen. Ein Zugang, der in einer Testumgebung mit lockereren Regeln liegt, aber Produktivrechte hat, ist ein klassisches Einfallstor.
• Beschränke, wer Zugangsdaten sehen oder exportieren darf. OWASP nennt das Prinzip der minimalen Rechtevergabe: Nicht jede Person im Team braucht Zugriff auf jeden gespeicherten Schlüssel, nur weil sie Workflows bauen darf.
• Wachse in einen dedizierten Secret-Manager hinein, sobald die Zahl der Integrationen steigt. Für ein, zwei Workflows reicht der Tool-eigene Speicher. Bei zehn Systemen und mehreren Personen im Team lohnt sich laut OWASP ein zentraler Secret-Manager mit Audit-Log — wer hat wann welchen Schlüssel angelegt, genutzt oder gelöscht.

Wie plant man Rechte und Rotation?

Rechte und Rotation sind die zwei Stellschrauben, die aus einer funktionierenden Automation eine dauerhaft sichere machen. Beide werden in der Praxis meist erst nachträglich eingeführt — nach einem Vorfall statt davor. Das eigene Prüfschema unten hilft, sie von Anfang an mitzudenken.

Rechte: Vergib pro Zugang nur die Scopes oder Rollen, die der jeweilige Workflow tatsächlich benötigt. Ein Workflow, der nur Kalendertermine lesen soll, braucht keinen Zugang mit Schreibrechten auf das gesamte Postfach. Bei OAuth ist das eingebaut (Scopes werden bei der Autorisierung sichtbar erteilt); bei API-Keys und Service Accounts musst du aktiv darauf achten, weil viele Anbieter standardmäßig weiterreichende Rechte vergeben, als der Workflow braucht.

Rotation: Google Cloud empfiehlt für Service-Account-Schlüssel eine regelmäßige Rotation nach festem Zeitplan, gerade weil kompromittierte, aber inzwischen ausgetauschte Schlüssel für Angreifer wertlos werden. OWASP zieht den gleichen Schluss für Maschinen-Zugangsdaten allgemein: automatisierte statt manuelle Rotation, weil manuelle Prozesse selten zuverlässig eingehalten werden. Bei OAuth übernimmt der Refresh-Mechanismus die Erneuerung des Zugriffstokens automatisch — das entbindet dich aber nicht davon, das zugrunde liegende Client-Secret der Anwendung selbst gelegentlich zu erneuern.

Dokumentation: Halte pro Zugang fest, wer ihn angelegt hat, wofür er verwendet wird und wann er zuletzt geprüft wurde. Ohne diese Notiz entsteht genau die Situation aus der Einleitung — ein Key, den niemand mehr zuordnen kann.

Eigenes Prüfschema: Welche Methode für welchen Fall?

Situation	Passende Methode	Worauf achten
Einzelner, einfacher API-Aufruf ohne sensible Daten (z. B. Wetterdaten, öffentliche Kursdaten)	API-Key	Key nur im Credential-Speicher des Tools, nie im Node-Text oder Kommentar
Workflow greift im Namen eines Menschen auf dessen Postfach, Kalender oder Cloud-Speicher zu	OAuth 2.0	Scopes so eng wie möglich wählen, Zugriff regelmäßig in den Kontoeinstellungen des Anbieters prüfen
Automation läuft dauerhaft, ohne dass eine Person angemeldet ist (nächtlicher Job, Server-zu-Server)	Service Account	Rechte explizit je Ressource vergeben, keine Domain-weite Delegation ohne triftigen Grund
Mehrere Workflows, mehrere Personen im Team, wachsende Zahl an Integrationen	Zentraler Secret-Manager statt verstreuter Tool-Speicher	Audit-Log führen, Zugriff nach minimaler Rechtevergabe staffeln
Zugang wurde von einer Person angelegt, die das Unternehmen verlassen hat	Sofort widerrufen und neu anlegen, nicht „laufen lassen”	Verantwortlichkeit für jeden Zugang von Anfang an dokumentieren

Eigenes Prüfschema Philogic Labs, aus Beratungs- und Umsetzungsprojekten mit n8n und angebundenen APIs.

Umsetzung: So gehst du vor

1. Bestandsaufnahme. Liste alle aktiven Zugangsdaten in deinen Automatisierungstools auf: Welcher Zugang, welches System, welcher Workflow, welche Person hat ihn angelegt. Diese Liste existiert in den meisten KMU noch nicht.
2. Methode je Zugang prüfen. Für jeden Eintrag: Passt API-Key, OAuth oder Service Account zur Situation, orientiert am Prüfschema oben? Ein OAuth-fähiger Dienst, der bislang über einen persönlichen API-Key eines einzelnen Mitarbeitenden läuft, ist ein typischer Kandidat für eine Umstellung.
3. Rechte reduzieren. Wo ein Zugang mehr kann, als der Workflow braucht, neu einrichten mit engerem Scope statt den bestehenden weiterzuverwenden.
4. Rotation und Verantwortlichkeit festlegen. Für jeden verbleibenden API-Key und Service-Account-Schlüssel ein Rotationsintervall und eine verantwortliche Person eintragen — auch wenn das anfangs nur eine einfache Tabelle ist.
5. Verlassenszugänge sofort bereinigen. Jeder Zugang, der einer Person zugeordnet ist, die das Unternehmen verlassen hat, wird beim Offboarding widerrufen, nicht erst beim nächsten Vorfall.

Wer diese fünf Schritte einmal durchgeht, hat danach nicht nur sicherere, sondern auch wartbarere Automationen — weil klar ist, was warum existiert.

Risiken & Grenzen

Ein paar Grenzen gehören zur ehrlichen Einordnung dazu, statt sie zu verschweigen:

• OAuth ist nicht überall verfügbar. Viele kleinere oder ältere APIs bieten ausschließlich API-Keys an. Dann bleibt die Absicherung über Speicherort, Rechteeinschränkung und Rotation die einzige Stellschraube.
• Mehr Sicherheit kostet Einrichtungsaufwand. Eine OAuth-Anbindung mit Client-Registrierung dauert länger als das Kopieren eines API-Keys. Für einen einmaligen Testworkflow ist das oft unverhältnismäßig — für einen produktiven, dauerhaften Prozess mit sensiblen Daten nicht.
• Service Accounts verschieben das Risiko, sie beseitigen es nicht. Ein kompromittierter Service-Account-Schlüssel mit weitreichenden Rechten kann größeren Schaden anrichten als ein einzelner API-Key mit engem Funktionsumfang. Die Rechtevergabe entscheidet, nicht die Methode allein.
• Kein technisches Verfahren ersetzt Prozesse. Rotation, Dokumentation und Offboarding sind organisatorische Aufgaben. Das beste Tool hilft nichts, wenn niemand zuständig ist, wenn eine Person das Unternehmen verlässt oder ein Projekt endet.
• Dieser Artikel ersetzt keine Sicherheits- oder Datenschutzberatung. Bei personenbezogenen oder besonders sensiblen Daten kommen zusätzlich Anforderungen aus der DSGVO hinzu, etwa zu Auftragsverarbeitung und Dokumentationspflichten — das ist ein eigenes Thema mit eigenen Regeln.

Wenn du deine bestehenden Workflows und deren Zugangsdaten nicht allein durchgehen willst: Wir prüfen n8n-Setups, API-Anbindungen und Rechtekonzepte im Rahmen einer KI- und Automatisierungsberatung und zeigen, wo unnötige Risiken liegen. Für ein erstes, unverbindliches Gespräch erreichst du uns über die Kontaktseite; wer die eigene Handhabung von Zugangsdaten im Team strukturiert schulen will, findet passende Formate in unseren Schulungen.

Checkliste: Zugangsdaten für Automationen absichern

1. Es existiert eine aktuelle Liste aller API-Keys, OAuth-Verbindungen und Service Accounts in unseren Automatisierungstools.
2. Für jeden Zugang ist dokumentiert, welche Person oder welches Team ihn angelegt hat und wofür er genutzt wird.
3. Wo OAuth verfügbar ist, nutzen wir es statt eines persönlichen API-Keys für Workflows mit Zugriff auf Postfächer, Kalender oder Cloud-Speicher.
4. Service Accounts haben nur Zugriff auf die konkret benötigten Ressourcen, nicht auf ganze Konten oder Ablagen.
5. Domain-weite Delegation bei Service Accounts ist die Ausnahme, nicht die Regel, und einzeln begründet.
6. Kein Zugang liegt im Klartext in Workflow-Notizen, geteilten Dokumenten oder Chatverläufen.
7. Für jeden API-Key und jeden Service-Account-Schlüssel ist ein Rotationsintervall festgelegt.
8. Zugänge von Personen, die das Unternehmen verlassen haben, werden beim Offboarding aktiv widerrufen.
9. Ab einer wachsenden Zahl an Integrationen ist ein zentraler Secret-Manager statt verstreuter Tool-Speicher im Gespräch.
10. Rechte sind nach dem Prinzip der minimalen Vergabe gestaffelt: Zugriff auf Zugangsdaten hat nur, wer ihn für seine Arbeit braucht.