Das Projekt findet sich hier auf Github: https://github.com/ateachment/SimpleAuthService/tree/jwt-based

Hintergrundinformation zu JSON Web Token: Exkurs: JSON Web Token

Hierbei wird das JWT wie empfohlen asynchron verschlüsselt, um auch die Authentizität des Ausstellers überprüfen zu können. Ein geeignetes Schlüsselpaar wird in der bash wie folgt generiert.

Erzeugung des Private Key:

openssl genrsa -aes256 -out private_key.pem 2048

Erzeugung des dazugehörigen Public Key:

openssl rsa -pubout -in private_key.pem -out public_key.pem

Benennen Sie die Datei settings-template.py in settings.py um und kopieren Sie die beiden Schlüssel zusammen mit dem verwendeten Kennwort in die Datei. (Vorsicht. Dabei darf kein Zeichen verloren gehen oder zuviel - auch kein Zeilenumbruch - hinzukommen.)

Die Verbindungsdaten für die Datenbank wird aus dem Installationsscript initdb.sql entnommen.

Immer noch ziemlich raffiniert

Allerdings wird mit der Verwendung von JWT gegenüber SWT (Simple Webtoken) einiges einfacher:

Zwei Vorteile von JWT

  1. Es müssen nicht mit jedem Seitenaufruf das Token im Backend z.B. mit Datenbankabfragen geprüft werden.
  2. Die Prüfung des JWT im Frontend passt daher eher zu dem zustandslosen HTTP-Protokoll.

Anders als beim SWT muss das JWT nicht mehr in der Datenbank gespeichert werden.

Allerdings ist die Verwendung von JWT in einem Punkt gegenüber SWT nachteilhaft:

Ein Nachteil von JWT

Auch ein JWT kann auch gestohlen werden. Im Gegensatz zu einem "harten" Logout bei klassischen serverseitigen Sessions (bei denen das Session-Token im Backend sofort ungültig gemacht wird), wird hier lediglich das JWT im Cookie- bzw. Browser-Speicher entfernt oder ungültig gemacht.

Wurde das JWT zwischenzeitlich gestohlen, so ist es weiterhin gültig, den die Verfallszeit ist ja nur im JWT als "exp"-Claim (expiry = dt. verfallen, ablaufen) selbst hinterlegt.

Maßnahmen zur Erhöhung der Sicherheit
Log out
  • Meldet sich ein Benutzer ab, so muss das im Browser gespeicherte JWT gelöscht oder ungültig gemacht werden.
  • Damit das JWT bei vergessener Abmeldung nicht dauerhaft gültig bleibt, muss eine angemessene Verfallszeit im JWT als exp-Clain festgelegt werden.
    Diese Verfallszeit wird bei Requests geprüft. Nach Ablauf dieser Zeit ist das JWT ungültig.
    Eine Verlängerung der Sitzung erfolgt üblicherweise durch die Ausstellung eines neuen JWT (z.B. mittels Refresh-Token.

Wird aus Sicherheitsgründen eine strenge Abmeldefunktionalität benötigt, die nicht auf den automatischen Ablauf des Tokens warten kann, obwohl das Token auf der Client-Seite gelöscht wurde, müssen doch zusätzliche Maßnahmen ergriffen werden:

  • Ein JWT wird nach einer Abmeldung nicht nur im Browser gelöscht, sondern außerdem serverseitig in einer Token-Revocation (dt. Widerruf) Liste aufgenommen (Blocked List /Deny List).
  • Bei jedem Request wird nicht nur das bereitgestellten JWT geprüft (Inhalt, Verfallsdatum usw.) sondern, falls die Autorisierung erfolgreich war, wird zusätzlich geprüft, ob dieses spezielle JWT nicht in dieser Liste geführt wird, also gestohlen wurde.

Aus Performancegründen kann diese Liste im Arbeitsspeicher geführt werden. Damit sie nicht zu groß wird, müssen diejenigen JWT, deren Verfallszeit abgelaufen ist, aus Liste entnommen werden. Dies kann z.B. mittels eines Cronjobs geschehen, der als eigener periodischer Prozess z.B. die Route /auth/cleanUp per DELETE aufruft. 
Falls der Webservice horizontal skalierbar sein soll, ist das Führen der Revocation-Liste in der Datenbank oder einem  verteilten Cache (z.B. Redis) empfehlenswert.

Quellen:

https://medium.com/devgorilla/how-to-log-out-when-using-jwt-a8c7823e8a6    (14.12.2022)
https://pyjwt.readthedocs.io/en/latest/usage.html#encoding-decoding-tokens-with-rs256-rsa     (14.12.2022)
https://flask-jwt.readthedocs.io/en/latest/     (14.12.2022)

Last modified: Friday, 27 February 2026, 9:36 AM