JSON WebToken sind eine intelligente Art, authentifizierung in seinen eigenen Webservice einzubinden. Sie sind unabhängig von Sessions und speichern ihre Daten nicht in einem Cookie, sodass so auch die Cookie-Richtlinie der Europäischen Union umgangen werden kann. Doch was ist so ein JSON WebToken eigentlich, und wie funktioniert er?
Grob gesagt sind JWTs (JSON WebToken) eine Kapselung von Daten, welche der Client nach erfolgter Authentifizierung vom Server erhält. Diese werden dann entsprechend gespeichert. Am einfachst wäre es, den JWT im LocalStorage abzuspeichern. Möchte sich der Client nun erneut beim Server authentifizieren, schickt dieser einfach den unveränderten JWT zum Server, und der Server validiert das Ganze dann. Der JWT selbst ist nach diesem Schema aufgebaut:
Header.Payload.Signature
Im Header wird spezifiziert, wie die Signatur gehasht wurde. Standardmäßig wird hierbei HS265 genutzt. In der Payload sind Daten enthalten, die der Client nutzen kann. Beispielsweise Informationen zum aktuell eingeloggten Nutzer wie Vorname, Name und E-Mail-Adresse. Der Client kann einfach auf diese unverschlüsselten Daten zugreifen und muss dafür nicht jedes Mal wieder den Server kontaktieren. Zum Schluss kommt die Signatur. Diese verleiht dem JWT die Gültigkeit. In ihr ist spezifiziert, wie lange der JWT gültig ist und wird bei jeder Anfrage an den Server auf die Gültigkeit überprüft. Ist der JWT nicht mehr gültig, so lehnt der Server die Anfrage schlicht ab.
Der JSON WebToken hat seine Anwendungsszenarien nicht nur im JavaScript Umfeld. Auch für Java, PHP oder andere Programmierumgebungen gibt es Bibliotheken, damit die eigene Software mit dem JWT umgehen kann. Vorteile des JWT sind, dass man auch auf andere Provider wie beispielsweise unabhängige Log-In Dienste setzen kann und diese recht einfach in den eigenen Dienst integrieren kann.
Weitere Informationen zum JWT sind auf der Webseite jwt.io zu finden. Dort gibt es auch eine Auflistung an Bibliotheken für eine Vielzahl an Programmiersprachen, um JWTs zu generieren und zu verifizieren. Dort lassen sich auch generierte JWT auf Gültigkeit überprüfen und schaueb, ob das generierte Konstrukt überhaupt ein korrekter JWT ist.
Bevor wir mit dieser neuen Meldung beginnen, nein, dies ist keine Bill Gates Verschwörungstheorie, von…
Dieses Mal möchten wir die Gelegenheit nutzen und Euch einen 3-in-1 Multifunktionsdrucker aus dem Hause…
Windows 11 tut sich wirklich schwer damit, Nutzer des Betriebssystems Windows 10 davon zu überzeugen,…
Die EU-Kommission hat ein Verfahren gegen den Facebook-Mutterkonzern Meta auf den Weg gebracht. Es geht…
Heute möchten wir Euch einen besonderen Deal vorstellen, denn er wird nicht nur als Amazon-Tipp…
Für viele Gamer ist Twitch mittlerweile die Anlaufstelle schlechthin, wenn es um Streaming geht. Das…
Diese Webseite benutzt Cookies.
Zeige Kommentare
Und, weil wir hier in Windows United sind, Asp.Net Core Web api ist der JWT eine gute Authentifizierungsmethode.
So schön JWT auch sein mag für Single-Sign-On, so gibt es leider auch einige Implementierungen, die fehlerbehaftet sind, und ihre Signaturen durcheinanderbringen. Außerdem sind solche Tokens leider schwer zu invalidieren. Typischerweise haben sie ein eingebautes Ablaufdatum. Solange es nicht überschritten wird, kann das Token verwendet werden, auch wenn man sich explizit ausgeloggt hat. Man muss also bei sicherheitskritischen Infrastrukturen darauf achten, dass man sich die "entwerten" Tokens beim Logout bis zu deren Ablauf merkt, damit kein anderer mehr dieses Token verwenden kann. Je nach Implementierung gab es dieses Problem aber auch schon bei Cookie-basierter Authentifizierung.
Was ich allerdings nicht verstehe: Was haben JWTs mit der Cookie-Richtlinie zu tun? Ist die Gesetzgebung wirklich so "dämlich" gewesen, die Richtlinie nur für Cookies vorzusehen? Denn, ob das Token jetzt im Local Storage liegt, und immer wieder zum Server übermittelt wird, oder dies via Cookies geschieht, macht fachlich genau gar keinen Unterschied, es wird einfach eine andere Technik verwendet. Und, wenn die Richtlinie wirklich nur auf Cookies ausgelegt ist, so ist es sicher nur eine Frage der Zeit, bis sie auf allgemeinere Mechanismen ausgeweitet wird, und man doch wieder einen Hinweis braucht. Da würde ich lieber auf Nummer sicher gehen, und den blöden Hinweis halt reinnehmen. :-)
Jap, die Richtlinie ist so "dämlich" ^^
In Windows Hello steckt (unter anderem) übrigens auch JWT drin.