Authentifizierung und Autorisierung

Wie sich Authentifizierung von Autorisierung unterscheidet und was QA zum Schutz des Zugriffs und zur Durchsetzung fachlicher Beschränkungen prüfen sollte.

Aktualisiert:

Inhalt

Authentifizierung und Autorisierung sind verschiedene Konzepte, die oft verwechselt werden. Diese Verwechslung kann dazu führen, dass QA Fehler unzutreffend beschreibt und echte Zugriffsrisiken übersieht.

  • →Authentifizierung fragt: „Wer bist du?“
  • →Autorisierung fragt: „Was darfst du tun?“

Die Eingabe von Benutzername und Passwort gewährt nicht automatisch Zugriff auf jede Ressource oder Aktion. Umgekehrt können manche Ressourcen ohne Anmeldung verfügbar sein, jedoch nur eingeschränkt. Diese Schichten getrennt testen.

Authentifizierung

Authentifizierung bestätigt die Identität eines Benutzers, Dienstes oder Geräts. Das System stellt fest, ob das Subjekt tatsächlich ist, wer es zu sein behauptet.

  • →Benutzername und Passwort
  • →Einmalcode
  • →MFA
  • →SSO
  • →Zugriffstoken oder ID-Token
  • →Zertifikat
  • →Zugangsdaten für die Kommunikation zwischen Maschinen

Authentifizierung geht über eine erfolgreiche Anmeldung hinaus und umfasst einen Lebenszyklus:

  • →Ein Benutzer oder System legt einen Berechtigungsnachweis vor
  • →Der Server validiert ihn
  • →Eine Sitzung wird angelegt oder ein Token ausgestellt
  • →Der Berechtigungsnachweis hat eine Gültigkeitsdauer
  • →Er kann ablaufen, widerrufen werden, beschädigt sein oder im falschen Kontext verwendet werden

Authentifizierungsprüfungen umfassen daher meist mehr als gültige und ungültige Anmeldeversuche.

Autorisierung

Nachdem das System ein Subjekt identifiziert hat, legt die Autorisierung fest, welche Aktionen es erlaubt.

  • →Ein gewöhnlicher Benutzer darf nur seine eigenen Bestellungen sehen
  • →Eine Führungskraft darf Bestellungen des Teams sehen
  • →Ein Administrator darf Benutzerstatus ändern
  • →Ein Integrationsdienst darf Daten lesen, aber nicht löschen
  • →Ein anonymer Benutzer darf eine öffentliche Seite öffnen, aber keinen persönlichen Kontobereich

Autorisierung bewertet Berechtigungen, Rollen, Richtlinien, Eigentümerschaft und fachliche Einschränkungen statt der Identität.

Auch einem erfolgreich authentifizierten Benutzer kann die Berechtigung für eine Aktion fehlen. Das ist eine eigene Zugriffskontrollschicht, kein Anmeldefehler.

Warum die Begriffe verwechselt werden

Fehler beider Arten können von außen ähnlich aussehen.

  • →Der Benutzer ist nicht angemeldet
  • →Sein Token ist abgelaufen
  • →Sein Token ist ungültig
  • →Er ist angemeldet, hat aber nicht die erforderliche Rolle
  • →Er hat die Rolle, versucht aber die Ressource eines anderen Benutzers zu öffnen
  • →Das Backend prüft den Zugriff falsch

Die UI kann all das als „Zugriff verweigert“ oder „Anmeldung erforderlich“ darstellen. QA muss Fehler, Ursachen und Prioritäten unterscheiden.

Authentifizierungsprüfungen für QA

  • →Gültige Zugangsdaten ermöglichen die Anmeldung
  • →Ungültige Zugangsdaten erlauben keine Anmeldung
  • →Abgelaufene Token und Sitzungen werden korrekt behandelt
  • →Die Abmeldung funktioniert korrekt
  • →Die Abmeldung macht die Sitzung wie gefordert ungültig
  • →Der Zugriff besteht nicht länger als vorgesehen
  • →Angemeldet bleiben, Refresh-Token, MFA und SSO funktionieren korrekt
  • →Zugangsdaten gelangen nicht über URLs, lokalen Speicher, Protokolle oder Netzwerkmitschnitte nach außen
  • →Wiederholte Anmeldung auf mehreren Geräten oder in mehreren Tabs verhält sich korrekt

Neben dem Erfolgsfall den gesamten Lebenszyklus der Berechtigungsnachweise testen. Viele Fehler entstehen bei Erneuerung, Ablauf, Widerruf und Wiederverwendung von Token oder Sitzungen statt bei der ersten Anmeldung.

Autorisierungsprüfungen für QA

  • →Benutzer sehen nur erlaubte Daten
  • →Benutzer führen nur erlaubte Aktionen aus
  • →Der Zugriff wird sowohl im Backend als auch in der UI durchgesetzt
  • →Direkte IDs legen keine Ressourcen anderer Benutzer offen
  • →Rollen haben keine übermäßigen Berechtigungen
  • →Funktionen hinter ausgeblendeten UI-Schaltflächen lassen sich nicht weiterhin über die API ausführen
  • →Regeln gelten einheitlich in Web-, Mobil- und API-Oberflächen
  • →Änderungen von Rolle, Status oder Objektzustand gewähren nicht versehentlich Berechtigungen

Autorisierung nur über die UI zu prüfen, ist eine häufige Falle. Eine ausgeblendete Schaltfläche belegt keinen Schutz. Wirksame Autorisierungstests enthalten fast immer direkte API-Aufrufe oder zumindest eine Prüfung der Backend-Antworten.

Häufige Fehler

  • →Der Austausch einer ID in einer Anfrage legt Daten eines anderen Benutzers offen
  • →Das Token des vorherigen Benutzers funktioniert nach der Abmeldung weiterhin
  • →Eine Rollenänderung in der Administration wird nicht zeitnah wirksam
  • →Ein Dienst prüft die Rolle, aber nicht die Eigentümerschaft des Objekts
  • →Das Frontend zeigt „verboten“, während das Backend die Anfrage ausführt
  • →Ein Zugriffstoken bleibt länger gültig als erwartet
  • →Kritische Ereignisse widerrufen Refresh-Token nicht
  • →Anonyme Benutzer erhalten mehr Daten als erlaubt

Diese Fehler sind für Produktqualität und Sicherheit oft bedeutsamer als gewöhnliche UI-Probleme.

Praktisches Beispiel

Betrachten wir ein Bestellsystem.

Benutzer A meldet sich an und öffnet Bestellung #1001. Dann ersetzt er die ID in einer Netzwerkanfrage oder URL durch #1002.

Liefert das System die Bestellung eines anderen Benutzers, war die Authentifizierung bereits erfolgreich. Die Autorisierung ist gescheitert, weil das Backend die Eigentümerschaft nicht geprüft hat.

Das ist eine entscheidende QA-Prüfung. Anmeldung und Token-Ausstellung können perfekt funktionieren, während eine schwache Zugriffskontrolle auf Ressourcen das Produkt trotzdem verwundbar macht.

Wichtige Erkenntnisse für QA

  • →Authentifizierung und Autorisierung sind getrennte Schichten.
  • →Authentifizierung prüft Identität; Autorisierung prüft Zugriff.
  • →Eine erfolgreiche Anmeldung erlaubt nicht jede Aktion.
  • →UI-Beschränkungen brauchen eine Durchsetzung im Backend, um zuverlässig zu schützen.
  • →Zugriff auf Daten und Aktionen anderer Benutzer ist ein wesentlicher Testbereich.
  • →Lebenszyklen von Token, Sitzungen und Rollen ebenso sorgfältig testen wie die Anmeldung selbst.

Weiterführende Informationen

Rollen- und Eigentümerschaftsmatrix für eine lokale Übung

Identität von der Berechtigung zum Zugriff auf ein bestimmtes Objekt trennen. In der lokalen Schulungs-Fixture gehört Datensatz 1 Benutzer A und Datensatz 2 Benutzer B. Ein Benutzer darf seinen eigenen Datensatz lesen; ein Administrator beide. Die Zeichenketten demo-user-a, demo-user-b und demo-admin sind synthetische Testdaten, keine echten Zugangsdaten.

plain text
Identität	Anfrage	Erwartet
Kein Token	GET /records/1	401 und WWW-Authenticate
Unbekanntes Token	GET /records/1	401 und keine Datensatzdaten
Benutzer A	GET /records/1	200, Eigentümer a
Benutzer A	GET /records/2	403, keine Eigentümer- oder Datensatzfelder
Benutzer B	GET /records/2	200, Eigentümer b
Administrator	GET /records/2	200, Eigentümer b
Benutzer A	POST /items mit gültigem Nachrichtenkörper	403 und kein neuer Eintrag

Beim verbotenen Objektzugriff neben dem Status auch den Antwortkörper prüfen: Ein Fehlercode zusammen mit fremden Benutzerdaten ist weiterhin ein Fehler. Eine 401-Antwort betrifft Berechtigungsnachweise; eine 403-Antwort bedeutet, dass die Operation verweigert wird. Ein echtes Produkt kann 404 verwenden, um die Existenz des Objekts zu verbergen. Erwartungen daher aus seinem Vertrag ableiten. Diese Fixture verwendet bewusst 403.

Die Fixture implementiert weder Anmeldung noch JWT-Prüfung, Ablauf, Widerruf oder Sitzungsspeicher. Diese Mechanismen separat in einer autorisierten Umgebung testen; die Ablehnung einer beliebigen unbekannten Zeichenkette beweist nicht, dass der Token-Ablauf funktioniert.

Weiterlernen

Lokales Übungslabor herunterladen (ZIP)

Token- und Zugangsdatenmechanismen

Negative Schreibtests und Nebenwirkungen

MDN: Antwort 401