Zum Hauptinhalt springen
Bethemesh
LeitfadenBewährte MethodenAnfänger

JWT: Aufbau, Signatur, Ablauf und typische Fehler verstehen

Lerne, was ein JWT enthält, warum Dekodieren keine Verifikation ist und wie Claims wie exp, nbf, iss und aud funktionieren.

Veröffentlicht 29. August 2026Lesezeit : 2 minVon Yann Bastien
Inhalt anzeigen
  1. Dekodieren ist nicht Verifizieren
  2. JWKS und kid sicher auswählen
  3. Mehr als nur die Signatur prüfen
  4. Vertrauliche Daten gehören nicht in den Payload
  5. Sessions und Speicherung bleiben Architekturfragen

Ein JSON Web Token besteht häufig aus drei Base64URL-kodierten Teilen: Header, Payload und Signatur. Der Payload ist lesbar; ein signiertes JWT ist normalerweise nicht verschlüsselt.

Dekodieren ist nicht Verifizieren

Jeder, der ein JWT besitzt, kann Header und Payload dekodieren. Das beweist weder die Signatur noch die Vertrauenswürdigkeit des Ausstellers. Der JWT-Decoder hilft beim Lesen der Struktur; der JWT-Inspector kann Signatur und Claims prüfen.

Für eine produktionsnahe Prüfung sollte die Anwendung die zulässigen Algorithmen selbst festlegen. Vertraue nicht darauf, dass ein untrusted alg-Wert im Token bestimmt, wie verifiziert wird.

JWKS und kid sicher auswählen

Ein JWT-Header kann ein kid enthalten. Bei einem JWKS sollte dieser Wert eindeutig den vorgesehenen Schlüssel auswählen. Fehlt die passende ID oder ist die Auswahl mehrdeutig, ist ein Fail-Closed-Verhalten sicherer als die Verwendung irgendeines Schlüssels.

Der JWK/JWKS-Inspector hilft beim Prüfen von Schlüsseltyp und Kennungen.

Mehr als nur die Signatur prüfen

Kontrolliere exp und gegebenenfalls nbf, außerdem den erwarteten Issuer iss und die Audience aud. Eine gültige Signatur allein bedeutet nicht, dass ein Token für deine Anwendung oder die angeforderte Aktion gültig ist.

Vertrauliche Daten gehören nicht in den Payload

Da ein normaler JWT-Payload lesbar ist, sollte er nicht als geheimer Speicher dienen. Halte Claims so klein wie möglich und vermeide unnötige personenbezogene oder vertrauliche Daten.

Sessions und Speicherung bleiben Architekturfragen

Ein gültiges Token kann gestohlen werden. Cookie-Eigenschaften, XSS-Schutz, Token-Laufzeit, Refresh-Strategie und Revocation beeinflussen das Risiko weiterhin. JWT ist ein Format, keine vollständige Session-Architektur.

Wie OAuth, PKCE, JWT und öffentliche Schlüssel zusammenspielen, erklärt OAuth 2.0, PKCE, JWT, JWK und JWKS. Der JWT-Encoder eignet sich für Lern- und Testdaten; produktive Ausstellung und Verifikation sollten richtliniengesteuert erfolgen.

War dieser Artikel hilfreich?