Ein JWT oder auch JSON Web Token ist zur Authentifizierung & Autorisierung gedacht, er kann sowohl von Clients und Servern gelesen werden. Er kann verwendet werden, um Daten sicher zwischen verschiedenen Anwendungen auszutauschen, durch die Signatur kann der JWT immer wieder mithilfe von JWKS verifiziert werden, dass eine Manipulation vom Inhalt ausgeschlossen werden kann.
Eine Definition des JWT Standards kann im RFC 7519 genauer nachgelesen werden, auf die wichtigsten Details werden wir im Abschnitt über den Aufbau von einem JWT betrachten.
JSON Web Tokens sind vorwiegend dann interessant, wenn es sich um eine Anwendung mit mehreren Microservices handelt, da dort der Nutzer häufig in verschiedene Systemen authentifiziert und autorisiert werden muss, um auf diese zugreifen zu dürfen. Ein Vorteil hier gegenüber einer Session ist, da der JWT eine Signatur zur Verifizierung enthält und eine Payload mit Informationen über den Nutzer. Es muss keine Kommunikation über einen Authentifizierungs-Server stattfinden bei jeder Anfrage, erst wenn der JWT abgelaufen ist, muss dieser wieder erneuert werden. Dadurch, dass die Payload zusätzliche Informationen über den Nutzer enthalten kann, muss nicht für jede Anfrage wieder eine Datenbank abgefragt werden, um Informationen über den Nutzer zu erhalten, diese können ganz bequeme bei der Erstellung im JWT gespeichert werden.
Der Vorteil von JSON Web Tokens ist auch gleichzeitig deren Nachteil, den man nicht außer Acht lassen sollte, dadurch das die Informationen im JWT gespeichert werden ist ein JWT ohne entsprechende zusätzliche Angaben unbegrenzt gültig. Es kann vorkommen, dass sich die Informationen eines Benutzers in der Datenbank ändern, während das zugehörige JWT-Token noch seine Gültigkeit behält – da der JWT nur über eine zeitliche Limitierung seine Gültigkeit erhält. Diese kann leicht zu unerwünschten Nebeneffekten führen, zum Beispiel, dass ein Nutzer von den Berechtigungen herabgestuft wird, aber sein alter JWT noch weiter verwendet werden kann, bis dieser zeitlich abläuft. Manche Systeme haben, um diese Problematik zu lösen, eine Sperrliste, wo solche JWT’s draufgeschrieben werden, die vorzeitig ihre Gültigkeit verlieren sollen, alle Microservices, die dann mit dem JWT arbeiten sollen, müssen diese noch einmal gegen validieren lassen. Dadurch verliert der JWT seine Unabhängigkeit von Dritten, um zu prüfen, ob der JWT noch verwendet werden darf.
Ein großer Einsatzbereich, wo JWT’s eine hervorragende Lösung sind, sind unter anderem die Single-Sign-Ons (SSO). Bei einem solchen Konzept ist im JWT etwa eine User-ID gespeichert, die von allen Anwendung verwendet wird, jede Anwendung hat noch mal eine eigene Datenbank, um anwendungsspezifische Informationen des Nutzers zu speichern. Im JWT könnte zum Beispiel auch als Information gespeichert sein, auf welche Anwendungen welcher Nutzer zugreifen darf. Diese geht, weil über die Signatur des JWT’s sichergestellt werden kann, dass der Inhalt nicht manipuliert wurde. Für diesen Zweck gibt es dann das sogenannte JSON Web Key Set (JWKS) diese ist ein JSON Dokument mit öffentlichen Schlüsseln, um die Signatur zu überprüfen, die mithilfe des privaten Schlüssels erstellt wurde.
Ein JSON Web Token besteht reguläre aus drei Teilen, oder in seltenen Fällen auch mal aus nur zwei Teilen. Ein JWT kann man an der Aufteilung erkennen HEADER.PAYLOAD.SIGNATUR – wobei der Header und die Payload Base64 encodiert werden.
Zum Beispiel könnte ein JWT Token wie folgt aussehen, wenn du ihn in der Webseite jwt.io einfügst, kannst du den Inhalt lesen, den reguläre ist die Payload lesbar. Alternative kann auch noch eine Verschlüsselung mittels JSON Web Encryption eingesetzt werden.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhlbGxvQ29kaW5nIiwiaWF0IjoxNTE2MjM5MDIyfQ.E7GPR9oycyTiXpnghy2Pxn43lUTgLjTUy_BMEYq4In4Der Header wird auch als JOSE (JSON Object Signing and Encryption) Header bezeichnet, den dieser enthält ausschließlich Informationen über die Signierung & Verschlüsselung.
Ein typischer Aufbau enthält, eine Angabe über den Algorithmus, mit dem die Signatur erstellt wurde und eine Definition, dass es sich um ein JWT handelt. Hierbei ist wichtig, dass, die Typangabe optional ist, aber gerne regulär auf JWT gesetzt wird. Diese ist relevant für Anwendungen, die auch andere, Typen wie einen Access Token akzeptieren, dieser aber in einer ähnlichen Datenstruktur auftritt, um die verschiedenen Typen dann einfach unterscheiden zu können.
{
"alg": "HS256",
"typ": "JWT"
}Es können verschieden Arten von Algorithmen verwendet werden, der HS256 (HMAC SHA-256) ist eine symmetrische Technik, wobei Sender und Empfänger beide den gleichen geheimen Schlüssel benötigen. RSA (Rivest-Shamir-Adleman) hingegen, ist eine Technik, wobei es einen öffentlichen und einen privaten Schlüssel gibt, der private Schlüssel wird verwendet, um die Signatur zu erstellen. Und der Öffentliche Schlüssel kann verwendet werden, um die Signatur vom JWT zum Beispiel wieder zu validieren als gültig.
Alternative zu den Algorithmen wie HS256 & RS256 kann auch „none“ als validiert Wert eingesetzt werden, in diesem Fall entfällt die Signatur.
Die Signatur oder auch JSON Web Signatur (JWS) genannt, definiert in RFC 7515. Grundsätzlich enthält der 3te Teil des JSON Web Tokens die Signatur.
Die Details zu JSON Web Encryption (JWE) würden hier etwas zu weit gehen, weshalb ich dir den Artikel von Scott Brady auf Englisch empfehlen will: https://www.scottbrady91.com/jose/json-web-encryption
Die Payload beinhaltet unterschiedlichste Informationen über den Nutzer, genauer gesagt die übermittelte Entität. Typischerweise werden die Keys im Payload Objekt nicht als Key bezeichnet, sondern als sogenannte Claims. Es gibt 3 verschiedene Arten von Claims:
exp für Expiration Time. Oder iss für den Herausgeber, meistens wird dort die URL des Authentifizierungs-Servers mitgegeben. Der Grund für die kurzen Namen ist, den JWT möglichst klein zuhalten.Eine Payload mit den verschiedenen Claim Typen könnte zum Beispiel folgendermaßen aussehen. Wir haben drei registrierte Claims für die sub, das Subjekt, die Entität, in unserem Fall eine User-ID, den Herausgeber (iss) des JSON Web Token. Und die Zeit, wann der Token abläuft, exp.
{
"sub": "user-id",
"iss": "https://hellocoding.de",
"exp": 169999999,
"name": "Felix",
"email": "office@hellocoding.de",
"https://hellocoding.de/game":{
"level": 10
}
}Zusätzlich haben wir jetzt noch zwei öffentliche Claims, um zu definieren, um welchen Nutzer es sich handelt, diese geschieht zwar auch über das Subject, aber so könnten wir in unsere Anwendung jetzt direkt den Nutzer begrüßen, ohne einen Server abfragen zu müssen.
Abschließend gibt es noch einen privaten Claim für ein Game, dort wird das aktuelle Level zum Beispiel drinnen gespeichert. Hier ist die Besonderheit, dass wir die URL verwenden, um eine Kollision mit anderen Claims ausschließen zu können.
Es ist wichtig zu beachten, es sollten niemals sensible Informationen wie Passwörter, Bankverbindungen in die Payload, auch wenn diese theoretisch möglich ist. Das Risiko von einem Hijacking kann niemals komplett ausgeschlossen werden. Auch unter einer Verschlüsselung mittels JWE kann ein Schlüssel mal an die Öffentlichkeit gelangen und schon können von externen die Daten gelesen werden.
Auch mit einer SSL Verbindung gibt es noch Sicherheitslücken für Hijacking, es ist etwa typisch, dass JWT's im Local Storage gespeichert werden. Das bedeutet das auch andere externe Script zum Beispiel auf diese zugreifen können, da der Local Storage nicht wie Cookies zusätzlich abgesichert werden kann, das diese zum Beispiel nur vom Server gelesen werden können.
Letztlich sollten sehr sensible Informationen wie Passwörter, Bankverbindungen etc. am besten immer direkt vom jeweiligen Service aus der Datenbank gelesen werden, genauer gesagt von einer Schnittstelle, die nicht für den Client zugänglich ist.
Grundsätzlich falls du den Gedanken hast im JWT ein Passwort unterzubringen, oder es bereits in einer Session hattest, solltest du einmal über das Konzept deiner Umsetzung nachdenken. Es gibt bestimmt auch einen alternativen Weg, der ohne ein dauerhaft gespeichertes Passwort funktionieren könnte.
Es gibt drei Bereiche, über die wir sprechen müssen, wenn es darum geht, was der Unterschied von einer Session zu einem JSON Web Token ist.
Um einen JWT nun zu erstellen, benötigen wir die drei definierten Teile: JOSE Header, Payload, JWS Signatur. Als Beispielsprache für die Erstellung des JWT verwende ich Python, das Beispiel lässt sich allerdings auch auf jede andere Sprache adaptieren.
Das Beispiel ist simple gehalten mit einem HS256, mit einem RS256 wird es etwas komplexerer bezüglich der Umsetzung, allerdings hab ich hier darauf verzichtet, da es grundsätzlich in jeder Sprache bereits JWT Paket gibt, die dir die Arbeit vereinfachen werden. Der Vollständigkeit halber wollte ich allerdings nicht auf ein Beispiel verzichten!
import json
import base64
import hmac
import hashlib
header = {"alg": "HS256", "typ": "JWT"} # unser JOSE Header
payload = {
"sub": "user-id",
"iss": "https://hellocoding.de",
"exp": 169999999,
"name": "Felix",
"email": "office@hellocoding.de",
"https://hellocoding.de/game": {"level": 10},
} # unser payload
# dein geheimer schlüssel
secret_key = "my_secret_key"
# payload & header
encoded_header = (
base64.urlsafe_b64encode(json.dumps(header).encode("utf-8"))
.rstrip(b"=")
.decode("utf-8")
)
encoded_payload = (
base64.urlsafe_b64encode(json.dumps(payload).encode("utf-8"))
.rstrip(b"=")
.decode("utf-8")
)
payload_header = f"{encoded_header}.{encoded_payload}"
# erstellen der Signatur
signature = (
base64.urlsafe_b64encode(
hmac.new(
secret_key.encode("utf-8"), payload_header.encode("utf-8"), hashlib.sha256
).digest()
)
.rstrip(b"=")
.decode("utf-8")
)
print(f"{payload_header}.{signature}") # der jwt tokenDen erhalten JWT können wir zum Testen zum Beispiel bei jwt.io decodieren lassen und nach dem wir auch unsere Secret eingesetzt haben, erhalten wir die Ausgabe, dass unsere Signatur Valide ist.
Nun sind wir so ziemlich am Ende angekommen, allerdings wirst du in den seltensten Fällen JWT komplett selbst implementieren wollen, sondern lieber auf eine Implementierung zurückgreifen.
Ich habe dir einmal meine persönlichen Empfehlungen für die verschiedensten Programmiersprachen herausgesucht.
Zusätzlich kann ich dir die Webseite https://jwt.io/libraries empfehlen, dort findest du eine Übersicht für viele andere Programmiersprachen wie Java, Golang, C++ und viel weitere.
Es gibt extreme viele Möglichkeiten für den Einsatz von JSON Web Tokens, beachten sollte man aber auch, dass ein JWT nicht immer die Lösung sein muss. Eine Session Handling kann je nach Anwendung auch eine sinnvolle Lösung sein.
Hast du Anmerkungen zu diesem Artikel? Oder auch eigene Erfahrungen mit JSON Web Tokens gemacht, die sowohl Positiv als auch Negativ waren, hinterlasse uns gerne deine Meinung.
Es sind noch keine Kommentare vorhanden? Sei der/die Erste und verfasse einen Kommentar zum Artikel "Was sind JSON Web Tokens? Wie funktioniert das Konzept?"!
