Begriff

Authorization

Security Identity S2

2 Quellen 1 Lernpfad 3 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Nach der Authentifizierung ("Wer bist du?") kommt die Autorisierung ("Was darfst du?"). Authenfizierung ist der Ausweis. Autorisierung ist der Schlüsselbund. Nur weil du Mitarbeiter bist (AuthN), darfst du nicht in den Tresorraum (AuthZ). Ein System muss prüfen: "Hat User Alice das Recht delete_database?" Wenn ja -> Aktion erlaubt. Wenn nein -> "403 Forbidden".

Merksatz: Der Prozess der Zuweisung und Überprüfung von Zugriffsrechten auf Ressourcen. Es entscheidet, ob ein authentifizierter Benutzer eine bestimmte Aktion ausführen darf.

Lernbruecke für Anfänger

Wenn du bei Authorization ganz neu startest, denke zuerst nicht an Fachwörter, sondern an die Alltagssituation: Rechte und Zugriffe trennen. 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.

Meistens über Rollen (Roles).

Admin: Darf alles.
Editor: Darf schreiben und lesen.
Viewer: Darf nur lesen. Wenn du dich einloggst, lädt die App deine Rollen. Im Code steht dann: if (user.role == 'Admin') { showDeleteButton() }. Das ist simpel, aber nicht sehr flexibel.

Praxisroutine

In der Praxis lernst du Authorization, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. RBAC vs. ABAC

RBAC (Role-Based Access Control): Du hast die Rolle "Manager". Manager dürfen "Approve". Einfach zu verwalten.
ABAC (Attribute-Based Access Control): Viel feiner. "User darf Dokument X lesen, WENN (User.Department == Dokument.Department) UND (Uhrzeit ist Werkstag) UND (User ist im VPN)." Das ist extrem mächtig ("Fine-Grained Authorization"), aber komplex zu implementieren (z. B. mit OPA - Open Policy Agent).

2. OAuth 2.0 Scopes

Bei APIs nutzt man Scopes im JWT Token. Scope: read:profile, write:orders. Die API prüft bei jedem Request: "Hat das Token den Scope write:orders?" Das ist "Delegated Authorization" – der User erlaubt der App, in seinem Namen zu handeln, aber nur begrenzt.

3. ReBAC (Relationship-Based Access Control)

Bekannt durch Google Zanzibar (das System hinter Google Drive). Berechtigungen basieren auf Graphen. "Alice darf File A lesen, weil File A im Folder B ist, und Folder B gehört Gruppe C, und Alice ist Mitglied von Gruppe C." Das System wandert den Graphen ab, um "Ja/Nein" zu entscheiden. Extrem schnell bei Millionen von Objekten.

OPA (Open Policy Agent) & Rego

Historisch war Autorisierungslogik tief in den Code der Applikation ("Spaghetti-Code") eingebacken. Moderne Architekturen "entkoppeln" AuthZ. Die App fragt einen externen Service: "Darf User X das tun?". Der Quasi-Standard dafür ist der Open Policy Agent (OPA). Policies werden bei OPA in einer deklarativen Sprache namens Rego geschrieben.

package app.rbac

default allow = false

allow {
    input.user.role == "admin"
}
allow {
    input.method == "GET"
    input.path == ["api", "public"]
}

Die App schickt ein JSON mit dem Kontext an OPA, OPA evaluiert das Rego-Skript extrem schnell im RAM und gibt true oder false zurück. Das ermöglicht es Security-Teams, Regeln zentral zu ändern, ohne die Applikation neu deployen zu müssen.

Google Zanzibar (Globale Scale ReBAC)

Wie prüft Google Drive in Millisekunden, ob du Datei X sehen darfst, wenn diese in Ordner Y liegt, der mit Gruppe Z geteilt ist, in der du Mitglied bist? Mit relationalen Datenbanken klappt das nicht bei Milliarden von Dateien. Google Zanzibar ist ihr internes AuthZ-System. Es normalisiert alle Berechtigungen in ein Format: Tuple(Object, Relation, User). Beispiel: (doc:123, viewer, group:456#member). Diese "Tupel" werden in gigantischen, weltweit verteilten Graph-Datenbanken (Spanner) gespeichert. Modernere Open-Source Klone wie SpiceDB (Authzed) bringen dieses ReBAC (Relationship-Based Access Control) Konzept in den Enterprise-Mainstream.

The Confused Deputy Problem

Ein klassisches AuthZ-Sicherheitsproblem. Bob darf Rechnungen ansehen, aber nicht löschen (sein Token hat Scope read:invoice). Bob sendet einen Request an die Rechnungs-App. Die Rechnungs-App muss intern die Datenbank ansprechen. Die App nutzt dafür oft ihr eigenes Service-Konto (das alles darf). Wenn Bob es schafft, der App einen fehlerhaften Parameter unterzujubeln, führt die App eine Löschung durch – als "verwirrter Stellvertreter". Die Lösung? Token Exchange (z.B. in OAuth 2.0). Die App nutzt Bobs Token, um sich beim Auth-Server ein neues Token in Bobs Namen ausstellen zu lassen, bevor sie die Datenbank aufruft. So wird Bobs eingeschränkter Scope über alle Microservices hinweg durchgesetzt ("Identity Delegation").

Quick-Check

Was ist IDOR?
Insecure Direct Object Reference. Ein häufiger AuthZ-Fehler. Ich ändere die URL von /orders/1 auf /orders/2 und sehe die Bestellung von jemand anderem, weil das System nur geprüft hat "Ist er eingeloggt?" aber nicht "Gehört ihm Order 2?".
Kann ich AuthZ ohne AuthN machen?
Nein. Um zu entscheiden, was jemand darf, muss ich erst sicher wissen, wer er ist. AuthN ist die Voraussetzung für AuthZ.
Wo entscheide ich AuthZ?
Immer server-seitig (Backend)! Niemals im Frontend (display: none beim Admin-Button ist kein Schutz, Hacker senden den API Request trotzdem).