JWT-Tokens Dekodieren, Verifizieren und häufige Fehler vermeiden

JWTs tauchen in fast jeder modernen Webanwendung auf — in Auth-Header, Refresh-Flows und API-Zugriffskontrolle. Sie sind jedoch eine der am häufigsten falsch eingesetzten Standards im Internet. Wenn Sie mit ihnen arbeiten, ist es unumgänglich, zu verstehen, was im Token enthalten ist, was Decodieren von Verifizieren tatsächlich bedeutet, und welche Kurzschlusswege Ihre Sicherheit schädigen.

Die Anatomie eines JWT

Ein JWT besteht aus drei base64url-gekodeten Strings, die durch Punkte verbunden sind:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImVtYWlsIjoiYWxpY2VAZXhhbXBsZS5jb20iLCJpYXQiOjE3MTI3NjQ4MDAsImV4cCI6MTcxMjg1MTIwMH0.4Xr8mNkZQWpH2TvL9uY3sKdJwFqBzEcAoMnRiVePxlU

• Kopfbereich — Algorithmus und Token-Typ (alg, typ)
• Nutzlast — die Ansprüche (die Daten, die Ihre Anwendung tatsächlich benötigt)
• Unterschrift — der HMAC- oder RSA-Unterschrift über die ersten beiden Teile

Decodiert sieht der Payload so aus:

{
  "sub": "user_123",
  "email": "alice@example.com",
  "iat": 1712764800,
  "exp": 1712851200
}

Dort ist nichts verschlüsselt. Jeder, der den Token besitzt, kann diese Werte lesen. Die Unterschrift beweist nur, dass der Token nach der Ausgabe nicht verändert wurde — sie versteckt nicht den Inhalt.

Decodieren ist nicht Verifizieren

Diese Unterscheidung verblödert mehr Entwickler, als es nötig wäre.

Decodieren teilt den Token an den Punkten auf und base64url-dekodiert jede Section. Kein Geheimnis erforderlich — jedes Tool oder eine Einzeilige kann dies tun. Wenn Sie ein JWT ohne Installation dekodieren möchten, fügen Sie den Token in IO Tools JWT Decoder ein und erhalten sofort die Header-, Payload- und Ablaufzeit-Aufteilung.

Verifizieren überprüft, ob die Unterschrift gültig ist, mit dem Geheimnis (oder dem öffentlichen Schlüssel bei asymmetrischen Algorithmen). Außerdem wird bestätigt, dass der Token nicht abgelaufen ist und dass die Ansprüche mit dem, was Ihre Anwendung erwartet, übereinstimmen. Das Verpassen der Verifikation und das Vertrauen in einen dekodierten Token führt zu Authentifizierungsverletzungen.

Hier ist ein Node.js-Codeausschnitt, der ein JWT verifiziert und die gängigen Randfälle behandelt:

import jwt from 'jsonwebtoken';

const SECRET = process.env.JWT_SECRET;

function verifyToken(token) {
  try {
    const payload = jwt.verify(token, SECRET, {
      algorithms: ['HS256'],  // whitelist — never allow 'none'
      audience: 'myapp',      // validate aud claim
    });

    // jwt.verify throws if exp is in the past, but be explicit:
    if (payload.exp < Math.floor(Date.now() / 1000)) {
      throw new Error('Token expired');
    }

    return payload;
  } catch (err) {
    // Never silently swallow verification failures
    throw new Error(`Invalid token: ${err.message}`);
  }
}

Ansprüche, die validiert werden sollten

Die JWT-Spezifikation definiert Standardansprüche, die Ihr Server aktiv überprüfen sollte, nicht nur lesen:

Claim	Bedeutung	Validieren Sie es?
exp	Ablaufzeitstempel	Immer — veraltete Tokens sind eine echte Angriffsoberfläche
iat	Ausgabedatumstempel	Optional, nützlich für max-age-Prüfungen
sub	Betreff (meistens Benutzer-ID)	Ja — stellen Sie sicher, dass es mit dem erwarteten Benutzer übereinstimmt
aud	Gegenseitige Zielgruppe	Ja — verhindert, dass Tokens von Dienst A auf Dienst B verwendet werden

Die meisten JWT-Bibliotheken validieren exp automatisch — aber nur, wenn Sie sie so konfigurieren. Lesen Sie die Dokumentation Ihrer Bibliothek. Nehmen Sie nicht an, dass sie standardmäßig aktiviert ist.

Drei Fehler, die Entwickler verbringen

1. Der alg: none Angriff

Die JWT-Spezifikation erlaubt einen Algorithmuswert von none, was bedeutet, dass keine Unterschrift vorhanden ist. Einige Bibliotheken — besonders ältere — akzeptieren diesen Wert und überspringen die Unterschriftsverifikation vollständig. Ein Angreifer entfernt die Unterschrift, setzt "alg": "none" im Header und fälscht beliebige Ansprüche. Der Server vertraut es.

Lösung: whiteliste explizit Algorithmen beim Verifizieren. Akzeptieren Sie niemals none. Der obige Codeausschnitt zeigt dies mit algorithms: ['HS256'].

2. Keine Ablaufzeitprüfung

Das Dekodieren eines Tokens und das Vertrauen auf den Payload ohne die Prüfung von exp bedeutet, dass ein Monat alt ausgegebene Token weiterhin akzeptiert werden. Wenn ein Benutzer seine Sitzung aufgegeben hat oder ein Angreifer ein altes Token gestohlen hat, weiß Ihre Anwendung nie davon.

Lösung: behandeln Sie die Ablaufzeit als obligatorisch, nicht als optional. Um zu prüfen, wann ein bestimmtes Token abläuft, IO Tools JWT Expiry Checker dekomprimiert die exp Behauptung und sagt Ihnen genau, wie viel Zeit noch bleibt — nützlich für die Debugging von Refresh-Flows ohne Code zu schreiben.

3. JWTs in localStorage speichern

localStorage ist für jedes JavaScript auf der Seite lesbar. Eine einzelne XSS-Vulnerabilität bedeutet, dass ein Angreifer Ihr Benutzersicherheits-Token stumm ausliefert. Hier ist ein Vergleich der Speicheroptionen:

Speicher	XSS-Risiko	CSRF-Risiko	Zugänglich aus JS	Hinweise
localStorage	Hoch	Keiner	Ja	Vermeiden für Authentifizierungstoken
sessionStorage	Hoch	Keiner	Ja	Die gleichen Risiken wie localStorage
httpOnly Cookie	Keiner	Medium	NEIN	Beste Option für Authentifizierung; kombinieren Sie mit SameSite + CSRF-Token
Im Speicher (JS-Variable)	Niedrig	Keiner	Ja (gleiche Kontext)	Verloren bei Aktualisierung; gut für kurzlebige Tokens

httpOnly-Cookies können von JavaScript überhaupt nicht gelesen werden, was die XSS-Abhörung vollständig eliminiert. Der Nachteil ist das CSRF-Risiko, das Sie mit SameSite=Strict oder einem CSRF-Token behandeln.

JWTs gegenüber Sessions: Die ehrliche Abwägung

JWTs sind stateless — der Server validiert sie ohne eine Datenbankabfrage. Das ist nützlich in verteilten Systemen, wo Sie nicht wollen, dass jedes Service eine gemeinsame Sitzungsdatenbank abfragt.

Aber stateless hat einen echten Preis: Sie können ein JWT nicht vor Ablauf widerrufen. Wenn ein Benutzer sich abmeldet oder kompromittiert wird, bleibt das Token gültig bis exp. Arbeiten (Token-Blocklisten, kurze Ablaufzeit + Refresh-Tokens) existieren, aber sie erhöhen die Komplexität und erzeugen oft das, was ein Sitzungsdatenbank bereits macht.

Verwenden Sie JWTs, wenn: Sie mehrere Dienste haben, die unabhängig auf Anfragen authentifizieren, wenn Sie Berechtigungen und Rollen direkt im Token integrieren möchten, oder wenn Ihre Tokens kurzlebig sind und eine Verzögerung bei der Widerrufung akzeptabel ist.

Verwenden Sie Sitzungen, wenn: Sie sofortige Widerrufung benötigen (Abmelden sollte tatsächlich funktionieren), Sie eine server-seitige Anwendung bauen oder wenn Einfachheit die Zustandslosigkeit überwiegt.

Ein Token in Sekunden überprüfen

Müssen Sie gerade sehen, was in einem JWT enthalten ist? Terminal:

echo "YOUR.JWT.HERE" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool

Oder überspringen Sie das Terminal — fügen Sie den Token in IO Tools JWT Decoder ein, um eine formatierte Aufteilung des Headers und Payloads zu erhalten. Beide Ansätze dekodieren nicht die Unterschrift; sie dekodieren nur. Für eine schnelle Ablaufzeitprüfung ohne Code zu schreiben, bietet der JWT Expiry Checker genau die Zeitstempel und die verbleibende Zeit an.

Das könnte Ihnen auch gefallen