Welche zwei Übergänge enden im Zustand „Zugriff abgelehnt“?

„Token ungültig“ von „Anfrage“ aus und „Eigentümer weicht ab“ von „Identität geprüft“ aus.

Ein Kunde ruft mit gültigem Token seine eigene Bestellung B-1042 auf. Welche Zustände durchläuft die Anfrage?

Anfrage, Identität geprüft, Zugriff erlaubt. Das Token ist gültig und der Kunde ist Eigentümer von B-1042.

Das Team will nur das Token prüfen und die Eigentümerprüfung sparen. Was spricht dagegen?

Das ist einfacher, aber jeder angemeldete Kunde könnte fremde Bestellkennungen aufrufen. Das gültige Token beweist nur die Identität, nicht das Recht an der Bestellung.

KonzeptKapitel III · Security · Baustein 4 von 7

Authentifizierung & Autorisierung

Authentifizierung stellt fest, welche Identität eine Anfrage stellt. Autorisierung prüft anschließend, ob diese Identität die gewünschte Ressource oder Handlung nutzen darf.

Von Michael Meierhoff · Meierhoff Systems

AuthentifizierungWer stellt die Anfrage?
AutorisierungDarf diese Identität das?
AblehnungZwei Wege führen zum Nein.

Einordnung

Warum das wichtig ist

Wer nur prüft, ob jemand angemeldet ist, gibt womöglich fremde Daten heraus. Erst die getrennte Frage, ob diese Identität die Ressource nutzen darf, schützt Bestellungen. Rollen und Grenzübergänge haben eigene Bausteine.

Dieser Baustein trennt Identität und Zugriffsentscheidung. Least Privilege gestaltet Rollen; Trust Boundaries markieren nötige Prüfungen am Übergang.

Auf einen Blick · Anmeldung und Token-Prüfung

Der Identity Provider stellt nach der Anmeldung ein Token aus; die API prüft es bei jeder Anfrage.

Shop-Beispiel · Zustände und Übergänge

Zugriff auf eine Bestellseite

Ein angemeldeter Kunde öffnet eine Bestellseite. Der Shop prüft das Sitzungstoken und gleicht anschließend die Kundenidentität mit dem Auftragseigentümer ab.

So liest du das Bild

Authentifizierung Zustand „Identität geprüft“: Token ist gültig und einem Kunden zugeordnet.
Autorisierung Übergang „Eigentümer stimmt überein“ führt zu „Zugriff erlaubt“.
Ablehnung Zwei Pfeile zu „Zugriff abgelehnt“: „Token ungültig“ und „Eigentümer weicht ab“.

Die Ressource wird erst nach erfolgreicher Identitäts- und Eigentümerprüfung ausgegeben.

Nutzen & Grenzen

Hilft, wenn

Unterschiedliche Nutzer, Dienste und Rollen benötigen differenzierte Zugriffsentscheidungen auf Funktionen und Daten.
Organisation, Eigentum, Zustand und Delegation prägen objektbezogene Autorisierung pro Anfrage.

Grenzen

Ein gültiges Token beweist nur die Identität; ob der Kunde diese Bestellung sehen darf, entscheidet die Autorisierung.
Versteckte Schaltflächen schützen nichts; der Server prüft Eigentümer und Aktion bei jedem Zugriff erneut.
Selbst korrekte Prüfung begrenzt den Schaden eines gestohlenen Tokens nicht; dafür sorgen Least Privilege und Secrets.

In der Praxis

Identitätsnachweis und Sitzung definieren. Bestimme, wie Identität festgestellt, erneuert und widerrufen wird. Kläre Gültigkeit und Kontext der übermittelten Nachweise. Das Ergebnis ist eine verlässliche Grundlage für nachgelagerte Berechtigungsentscheidungen.
Autorisierungsregeln ausdrücken. Definiere Subjekt, Aktion, Ressource und Kontext als getrennte Kriterien. Lege fest, welche Rolle, Eigentums- oder Zustandsbedingung erfüllt sein muss. Damit lassen sich Entscheidungen nachvollziehbar erklären und testen.
Geprüfte Zugriffspfade testen. Prüfe erlaubte und verbotene Anfragen über ausgewählte UI-, API- und Hintergrundpfade einschließlich Rollenwechsel und Widerruf. Erfasse Ablehnungen und Fehlkonfigurationen. Das Ergebnis belegt, wie die getesteten Pfade Identität und Berechtigung durchsetzen.

Ausführliche Erklärung lesen

Authentifizierung prüft, wer eine Anfrage stellt, und bindet sie an eine Identität. Autorisierung bewertet anschließend Subjekt, Aktion, Ressource und Kontext. Rollen können Fähigkeiten ausdrücken; Eigentum, Mandantenzuordnung und Objektzustand ergänzen häufig die Entscheidung. Die Prüfung baut auf Trust Boundaries auf und begrenzt sich durch Least Privilege.

Eine erfolgreiche Anmeldung gewährt keinen automatischen Zugriff auf beliebige Objektkennungen. Jede relevante Lese- oder Änderungsoperation braucht eine serverseitige Entscheidung. Oberflächen können Funktionen verständlich präsentieren, übernehmen aber keine Schutzwirkung für direkte Anfragen. Widerruf, Rollenwechsel und Delegation beeinflussen den Kontext und müssen in den Zugriffspfaden berücksichtigt werden. Die Entscheidung kann rollenbasierte Fähigkeiten mit Ressourcenbezug und Objektzustand kombinieren. Damit bleibt eine allgemeine Rolle von der konkreten Freigabe einer einzelnen Operation unterscheidbar.

OAuth 2.0 regelt delegierte Autorisierung; OpenID Connect ergänzt darauf eine Schicht zur Authentifizierung.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Welche zwei Übergänge enden im Zustand „Zugriff abgelehnt“?
Lösung mit Begründung ansehen
„Token ungültig“ von „Anfrage“ aus und „Eigentümer weicht ab“ von „Identität geprüft“ aus.
AnwendenAuf eine neue Lage übertragen
Ein Kunde ruft mit gültigem Token seine eigene Bestellung B-1042 auf. Welche Zustände durchläuft die Anfrage?
Lösung mit Begründung ansehen
Anfrage, Identität geprüft, Zugriff erlaubt. Das Token ist gültig und der Kunde ist Eigentümer von B-1042.
BewertenEine Alternative abwägen
Das Team will nur das Token prüfen und die Eigentümerprüfung sparen. Was spricht dagegen?
Lösung mit Begründung ansehen
Das ist einfacher, aber jeder angemeldete Kunde könnte fremde Bestellkennungen aufrufen. Das gültige Token beweist nur die Identität, nicht das Recht an der Bestellung.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Security & Risiken: Secrets.

7 Bausteine

Weiter mitSecrets