Autorisierung – Authorization (AuthZ) – bezeichnet den Prozess, durch den ein System nach erfolgreicher Authentifizierung entscheidet, welche Aktionen eine verifizierte Identität ausführen darf: „Du bist wer du sagst – aber darfst du das auch tun?“ Während Authentifizierung die Identität verifiziert, regelt Autorisierung die Berechtigungen: Welche Ressourcen darf ich sehen? Welche Aktionen darf ich ausführen? Auf welche Daten habe ich Zugriff?
Authentifizierung und Autorisierung werden häufig verwechselt oder zusammen als „Zugriffskontrolle“ bezeichnet – sind aber konzeptionell getrennte Schritte, die unabhängig versagen können: Ein System kann die Identität korrekt prüfen (gute Authentifizierung), aber dann falsche Rechte vergeben (schlechte Autorisierung). Oder umgekehrt: sehr granulare Berechtigungen, die aber durch ein schwaches Passwort kompromittierbar sind.
Authentifizierung vs. Autorisierung
Authentifizierung (AuthN)
- Frage: Wer bist du?
- Identität verifizieren
- Passwort, MFA, Zertifikat
- Ergebnis: bestätigte Identität
- Kommt zuerst
Autorisierung (AuthZ)
- Frage: Was darfst du tun?
- Berechtigungen prüfen
- Rollen, Rechte, Policies
- Ergebnis: erlaubte Aktionen
- Kommt nach Authentifizierung
Autorisierung in Automatisierungsplattformen
- API-Level-Autorisierung:Jeder API-Aufruf eines Workflows wird gegen die Berechtigungen des Service-Accounts geprüft – nicht nur beim Login, sondern bei jeder einzelnen Aktion
- Datenbankberechtigungen:Datenbanknutzer haben nur SELECT/INSERT/UPDATE auf explizit definierten Tabellen – kein generelles Datenbankrecht
- Workflow-interne Autorisierung:Workflow-Schritte, die auf sensitive Daten zugreifen, prüfen vorher, ob der auslösende Kontext berechtigt ist
- Fehler sicher behandeln:Unauthorized-Responses (HTTP 401 vs. 403) klar unterscheiden – 401 = nicht authentifiziert, 403 = authentifiziert aber nicht autorisiert
- Audit-Log für Autorisierungsfehler:Abgelehnte Autorisierungsversuche protokollieren – häufige 403-Fehler von einem Service-Account können auf Missbrauch oder Konfigurationsfehler hinweisen
Praxisbeispiel
Ein Automatisierungsworkflow für Bestellabwicklung scheitert plötzlich bei einem Kunden mit HTTP 403 (Forbidden). Diagnose: Authentifizierung erfolgreich (API-Key korrekt) – das System weiß, wer der Workflow ist. Autorisierung fehlgeschlagen – der Workflow hat keine Berechtigung mehr für den API-Endpunkt. Ursache: Der Kunde hat seine API-Berechtigungen überarbeitet und dabei den Service-Account des Workflows von der „Bestellungen schreiben“-Berechtigung ausgeschlossen. Die klare Trennung zwischen AuthN (wer?) und AuthZ (darf?) macht die Diagnose sofort klar: Es ist kein Authentifizierungsproblem (der Key ist gültig), sondern ein Autorisierungsproblem (die Berechtigung fehlt). Lösung: Kunde ergänzt den Service-Account in seiner Berechtigungsverwaltung. Downtime: 23 Minuten. Ohne klare AuthN/AuthZ-Trennung im Error-Handling hätte die Diagnose Stunden gedauert.
