Der Client erhält vom Authorisationsservice ein Token. Dieses muss er lokal speichern und bei jedem Request mitsenden.
Ein Webbrowser als Client hat verschiedene Möglichkeiten, um Daten zu speichern. Je nach Art des Speichers haben wir gewisse Vor- und Nachteile.
In Cookies können Daten gespeichert und weitergeleitet werden. Cookies werden bei einem Request automatisch durch den Webbrowser mitgesendet. Diese haben einen schlechten Ruf, da sie oftmals zur Verfolgung von Benutzeraktivitäten über verschiedene Webseiten hinweg verwendet wurden bzw. noch werden.
Auch der Local Storage bietet eine Datenablage. Im Gegensatz zu Cookies werden Werte nicht automatisch gespeichert und gesendet. Beides muss explizit durch Javascript programmiert werden. Die Daten im Local Storage haben kein Ablaufdatum und werden auch über mehrere Browser Sessions hinweg geteilt.
Der Unterschied zum Local Storage besteht darin, dass Session Storage nur für eine Browser Session gilt. Die Daten werden automatisch gelöscht, wenn die Seite geschlossen wird. Da ein Authentifizierungs-Token sowieso nicht lange gültig ist, bietet sich aus meiner Sicht der Session Storage als Speicherort an.
Ein Webbrowser kann auch Daten in einer Datei auf dem Clientrechner speichern.
Über den Bezeichner “sessionStorage” können wir diesen Speicher verwalten.
Die Methode setItem
speichert meine Daten als Key/Value-Pair:
data = ... sessionStorage.setItem("token", data);
Bei jedem Request muss der Client sein Token mitsenden.
Dazu wird beim Request ein zusätzlicher Authorization
-Header gesendet.
In diesem Header ist es üblich, das Schlüsselwort Bearer
vor das eigentliche Token zu stellen.
token = sessionStorage.getItem("token"); fetch("./????", { method: "POST", headers: { "Content-Type": "application/x-www-form-urlencoded", "Authorization": "Bearer " + token }, body: data }) ...
In unserer Webapplikation können wir über den Request-Header Authorization
auf das mitgesendete Token zugreifen.
Zunächst prüfen wir, ob ein Authorization
-Header vorhanden ist.
Danach können wir das Token ab Position 8 aus diesem Header lesen.
Wir stellen ja beim Senden das Schlüsselwort Bearer
vor das eigentliche Token.
Daher müssen wir diese 7 Zeichen beim Verarbeiten des Tokens wieder entfernen.
Anschliessend müssen wir prüfen ob das Token gültig ist. Die einzelnen Schritte sind:
Zum Glück sind viele der komplizierteren Aufgaben in entsprechenden Bibliotheken für uns gelöst. Schaue dir dazu das Umsetzungsbeispiel an.