Woher weiß ein Server nach der Anmeldung, dass jede spätere Anfrage wirklich von Ihnen stammt? Eine beliebte Antwort ist ein JSON Web Token oder JWT, normalerweise ausgesprochen „jot“. Dabei handelt es sich um kleine, signierte Daten, die der Client bei jeder Anfrage sendet und die der Server überprüfen kann, ohne eine Datenbank anzugreifen.

Der schnellste Weg, ein JWT zu verstehen, besteht darin, eines zu erstellen und dann zu versuchen, es zu zerstören. Wir haben das nur mit der Standardbibliothek von Python auf Python 3.13 gemacht, und die folgende Ausgabe stammt von diesem Lauf. Dieser Code dient zum Lernen. Verwenden Sie in einer realen Anwendung eine gut gepflegte Bibliothek, da es bei den Details der Verifizierung leicht zu Fehlern kommen kann.

Was ist ein JWT?

JWT ist ein offener Standard, definiert in RFC 7519, zur Weitergabe von Ansprüchen zwischen zwei Parteien als kompakte Zeichenfolge. Ein Anspruch ist einfach eine Aussage, wie zum Beispiel „Die ID dieses Benutzers ist 42“. Da der Token signiert ist, kann der Empfänger bestätigen, wer ihn ausgegeben hat und dass niemand ihn verändert hat.

Denken Sie an ein Festival-Armband. Die Mitarbeiter am Gate kontrollieren Ihr Ticket einmal und geben Ihnen ein Band, das schwer zu fälschen ist. Danach blickt jeder Stand nur noch auf die Band, ohne dass ein Anruf beim Ticketschalter erforderlich ist. Ein JWT funktioniert für eine API weitgehend auf die gleiche Weise.

So funktioniert die JWT-Anmeldung

1. Der Benutzer sendet einen Benutzernamen und ein Passwort an den Anmeldeendpunkt.
2. Der Server prüft sie und erstellt ein signiertes Token.
3. Der Client speichert den Token.
4. Jede spätere Anfrage enthält es, normalerweise in einem Header: Authorization: Bearer <token>.
5. Der Server überprüft die Signatur und das Ablaufdatum und liest dann die Ansprüche.

Der Hauptvorteil liegt in Schritt 5. Der Server muss nicht nach einer Sitzung suchen, was praktisch ist, wenn viele Dienste oder Server dasselbe Token überprüfen müssen. Wenn Sie mit APIs noch nicht vertraut sind, beginnen Sie mit Was ist eine API?.

Die drei Teile eines JWT

Ein JWT sieht aus wie zufälliger Text, besteht jedoch aus drei Base64URL-codierten Abschnitten, die durch Punkte getrennt sind. Hier ist eines, das wir generiert haben:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzkzNTAwMDAwLCJleHAiOjE3OTM1MDA5MDB9
.7YfUDH_T-iDh8bMmUT8mmKYwOstzT8Ty--DTTAmQGWM

Zur besseren Lesbarkeit haben wir Zeilenumbrüche eingefügt. Die Dekodierung der ersten beiden Teile ergibt einfaches JSON:

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"42","role":"user","iat":1793500000,"exp":1793500900}

Standardansprüche

Sie können auch benutzerdefinierte Ansprüche hinzufügen, z. B. role. Zeiten sind Unix-Zeitstempel in Sekunden. Halten Sie die Nutzlast klein, da der Token bei jeder Anfrage übertragen wird.

Bauen Sie selbst eins

Zum Erstellen eines Tokens müssen die beiden JSON-Teile codiert und anschließend mithilfe von HMAC-SHA256 mit einem Geheimnis signiert werden:

import base64, hashlib, hmac, json

SECRET = b"demo-secret-do-not-use-in-production"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(message):
    return b64url(hmac.new(SECRET, message.encode(), hashlib.sha256).digest())

def create_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    parts = [
        b64url(json.dumps(header, separators=(",", ":")).encode()),
        b64url(json.dumps(payload, separators=(",", ":")).encode()),
    ]
    message = ".".join(parts)
    return message + "." + sign(message)

Bei der Verifizierung wird die Signatur neu berechnet und mit der Signatur im Token verglichen. Nur jemand, der das Geheimnis kennt, kann ein passendes herstellen:

def verify_token(token, now):
    header, payload, signature = token.split(".")
    expected = sign(header + "." + payload)
    if not hmac.compare_digest(signature, expected):
        raise ValueError("bad signature")
    claims = json.loads(b64url_decode(payload))
    if claims["exp"] < now:
        raise ValueError("token expired")
    return claims

Ein gültiger Token hat seine Ansprüche wie erwartet zurückgegeben. compare_digest wird verwendet, da es in konstanter Zeit läuft, wodurch ein Informationsverlust durch Zeitunterschiede vermieden wird.

Versuchen Sie es zu manipulieren

Angenommen, ein Angreifer dekodiert die Nutzlast, ändert "role":"user" in "role":"admin", kodiert sie erneut und behält die alte Signatur. Wir haben dies zusammen mit zwei anderen Angriffen versucht:

Dieser letzte Versuch zielt auf eine echte historische Schwäche ab. Einige Bibliotheken vertrauten einst dem Header des Tokens, sodass ein Angreifer einfach erklären konnte, dass keine Signatur erforderlich sei. Unser Code verwendet immer einen festen Algorithmus, weshalb er abgelehnt wurde. Geben Sie in einer echten Bibliothek immer die Algorithmen an, die Sie akzeptieren.

Signiert, nicht verschlüsselt

Dies ist der am meisten missverstandene Punkt bei JWTs. Unser gefälschter Token wurde abgelehnt, sein Inhalt war jedoch weiterhin einwandfrei lesbar:

{"sub":"42","role":"admin","iat":1793500000,"exp":1793500900}

Base64URL ist eine Kodierung, keine Verschlüsselung, und jeder kann sie ohne Schlüssel rückgängig machen. Die Signatur verhindert, dass Personen die Daten ändern, aber nicht, sie zu lesen. Geben Sie daher niemals Passwörter, Kartennummern oder private persönliche Daten in eine JWT-Nutzlast ein. Wenn der Inhalt ausgeblendet werden muss, verwenden Sie verschlüsselte Token (JWE) oder belassen Sie die Daten einfach auf dem Server.

HS256 vs. RS256

Mit asymmetrischer Signatur können andere Dienste Token verifizieren, ohne ihre eigenen prägen zu können, was den Schaden begrenzt, wenn einer kompromittiert wird.

JWT vs. Sitzungen

JWTs werden oft als moderner Ersatz für Sitzungen präsentiert. In Wirklichkeit gibt es bei beiden Kompromisse:

Für eine herkömmliche, vom Server gerenderte Website ist ein Sitzungscookie oft einfacher und sicherer. JWTs sind tendenziell sinnvoller für APIs, die von mehreren Diensten genutzt werden, oder für mobile Clients.

Wo Token in einem Browser gespeichert werden

Viele Sicherheitsleitfäden bevorzugen HttpOnly, Secure, SameSite Cookies für Web-Apps. Was auch immer Sie wählen, verwenden Sie immer HTTPS. Informationen zum Senden eines Tokens aus JavaScript finden Sie in unserem JavaScript Fetch API-Tutorial.

Token aktualisieren

Ein kurzer Ablauf begrenzt den Schaden durch einen gestohlenen Token, aber niemand möchte sich alle 15 Minuten anmelden. Die übliche Lösung verwendet zwei Token:

• Zugriffstoken: ist von kurzer Dauer, z. B. Minuten, und wird mit jeder API-Anfrage gesendet.
• Aktualisierungstoken: langlebiger, sorgfältiger gespeichert und nur zum Erhalten neuer Zugriffstoken verwendet.

Der Server verfolgt die Aktualisierungstokens, sodass er diese widerrufen kann, was Ihnen eine praktische Abmeldung ermöglicht. Wenn Sie sie bei jeder Verwendung wechseln, können Sie außerdem einen Diebstahl erkennen, da ein gestohlener alter Token erneut abgespielt wird.

Häufige Sicherheitsfehler

• Dekodierung ohne Verifizierung. Das Lesen einer Nutzlast macht sie nicht vertrauenswürdig. Überprüfen Sie immer die Signatur.
• Jeden Algorithmus akzeptieren. Legen Sie eine explizite Liste zulässiger Algorithmen fest.
• Verwendung eines schwachen Geheimnisses. Kurze Geheimnisse können offline geknackt werden. Verwenden Sie einen langen Zufallswert und halten Sie ihn außerhalb der Quellcodeverwaltung.
• Ablaufdatum überspringen. Token ohne exp können bei Diebstahl für immer funktionieren.
• iss und aud werden nicht überprüft. Andernfalls kann ein für einen Dienst ausgestelltes Token von einem anderen akzeptiert werden.
• Veralteten Ansprüchen vertrauen. Eine Rolle innerhalb eines Tokens kann veraltet sein, bis es abläuft.
• Protokollierungs-Tokens. Jeder, der Ihre Protokolle liest, könnte sie wiederverwenden.
• Fehlerpfade werden nicht getestet. Fügen Sie Tests für abgelaufene und geänderte sowie gültige Token hinzu. Unser Leitfaden zum API-Testen mit Postman kann hilfreich sein.

Fazit

Bei einem JWT handelt es sich um signierte Daten, denen ein Server ohne Nachschlagen vertrauen kann, kein geheimer Container und kein automatisches Upgrade über Sitzungen hinweg. Verwenden Sie eine kurze Ablauffrist, überprüfen Sie alles mit einer gepflegten Bibliothek und halten Sie private Daten von der Nutzlast fern. Um es selbst zu sehen, führen Sie ein kleines Skript wie unseres aus, ändern Sie ein Zeichen eines Tokens und beobachten Sie, wie die Überprüfung fehlschlägt.

Häufige Fragen

Lerne weiter