Authentifizierung klärt, wer jemand ist. Autorisierung klärt, was diese Person darf.
Beide laufen direkt hintereinander ab und landen oft in einem Topf namens „Login“. Dabei können sie unabhängig scheitern – und der Server antwortet dann mit unterschiedlichen Fehlercodes.
Bei der Authentifizierung gleicht der Server eine Angabe wie Passwort oder Token (ein Ausweis-Datenstück aus Buchstaben und Zahlen) mit seinen gespeicherten Daten ab. Daraus ermittelt er eine Identität, etwa die Nutzer-ID 42. Das ist der erste Schritt: Ohne feststehende Identität kann keine Rechteprüfung folgen.
Bei der Autorisierung prüft der Server für jede einzelne Anfrage, ob diese Identität die angefragte Aktion ausführen darf. Konkret: Nutzer 42 meldet sich mit Passwort an. Beim Aufruf von DELETE /artikel/7 prüft der Server zusätzlich, ob 42 die Rolle Redakteur hat. Ohne diese Rolle folgt der Statuscode 403.
Scheitert die Authentifizierung, antwortet der Server mit 401 (nicht authentifiziert). Scheitert nur die Autorisierung, folgt 403 (verboten) – die Identität ist bekannt, aber die Rechte fehlen.
Weil HTTP zustandslos ist – jede Anfrage steht für sich –, muss jede Anfrage die Identität erneut belegen, etwa durch ein Cookie, ein Name-Wert-Paar, das der Server setzt und der Browser zurücksendet, mit einer Sitzungs-ID als Verweis auf die serverseitig gespeicherte Anmeldung. Der Server authentifiziert also bei jeder Anfrage von Neuem. Und weil der Browser-Seite nicht vertraut werden kann, gehört jede dieser Prüfregeln zusätzlich ins Backend.
Faustregel: Erst die Identität feststellen, dann je Anfrage die Rechte prüfen – beide Prüfungen niemals nur im Browser.
Authentifizierung heißt nicht „eingeloggt und alles erlaubt“, sondern nur „erkannt“. Was jemand darf, entscheidet die Autorisierung – separat und bei jedem Zugriff neu.
📌 Identität · Rechte · 401 vs. 403
📚 Webentwicklung von Grund auf · Tag 4 von 30
#WebSecurity #backend #HTTP
Beide laufen direkt hintereinander ab und landen oft in einem Topf namens „Login“. Dabei können sie unabhängig scheitern – und der Server antwortet dann mit unterschiedlichen Fehlercodes.
Bei der Authentifizierung gleicht der Server eine Angabe wie Passwort oder Token (ein Ausweis-Datenstück aus Buchstaben und Zahlen) mit seinen gespeicherten Daten ab. Daraus ermittelt er eine Identität, etwa die Nutzer-ID 42. Das ist der erste Schritt: Ohne feststehende Identität kann keine Rechteprüfung folgen.
Bei der Autorisierung prüft der Server für jede einzelne Anfrage, ob diese Identität die angefragte Aktion ausführen darf. Konkret: Nutzer 42 meldet sich mit Passwort an. Beim Aufruf von DELETE /artikel/7 prüft der Server zusätzlich, ob 42 die Rolle Redakteur hat. Ohne diese Rolle folgt der Statuscode 403.
Scheitert die Authentifizierung, antwortet der Server mit 401 (nicht authentifiziert). Scheitert nur die Autorisierung, folgt 403 (verboten) – die Identität ist bekannt, aber die Rechte fehlen.
Weil HTTP zustandslos ist – jede Anfrage steht für sich –, muss jede Anfrage die Identität erneut belegen, etwa durch ein Cookie, ein Name-Wert-Paar, das der Server setzt und der Browser zurücksendet, mit einer Sitzungs-ID als Verweis auf die serverseitig gespeicherte Anmeldung. Der Server authentifiziert also bei jeder Anfrage von Neuem. Und weil der Browser-Seite nicht vertraut werden kann, gehört jede dieser Prüfregeln zusätzlich ins Backend.
Faustregel: Erst die Identität feststellen, dann je Anfrage die Rechte prüfen – beide Prüfungen niemals nur im Browser.
Authentifizierung heißt nicht „eingeloggt und alles erlaubt“, sondern nur „erkannt“. Was jemand darf, entscheidet die Autorisierung – separat und bei jedem Zugriff neu.
📌 Identität · Rechte · 401 vs. 403
📚 Webentwicklung von Grund auf · Tag 4 von 30
#WebSecurity #backend #HTTP
2 Tage vor
