logo
GeekFormat

JWT Decoder, Verifizierer & Generator

Encoded Token172 charsAktualisiert 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Subjekt1234567890
name· NameJohn Doe
admin· Admintrue
iat· Ausgestellt um151623902218.01.2018, 09:30:22
Header details2 items
algHS256HMAC (symmetrisch)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Kostenlose Online-JWT-Werkbank: JSON Web Tokens decodieren, verifizieren und generieren. Unterstützt 13 Algorithmen (HS256 / RS256 / ES256 / PS256 / EdDSA usw.). Sowohl PEM- als auch JWK-Schlüssel. Automatische Schlüsselpaar-Generierung. exp/iat/nbf automatisch analysiert. 100% clientseitig — Token verlässt nie Ihren Browser.

Ähnliche Tools

Anwendungsfälle

  • JWT online decodieren: Token schnell während des OAuth 2.0 / OIDC Login-Debuggings aufteilen, um Header-Algorithmus und Payload-Claims zu inspizieren
  • JWT-Signaturen verifizieren: Secret / öffentlichen Schlüssel verwenden, um Token-Signaturen in Echtzeit zu validieren und zu entscheiden, ob ein 401 'falsche Signatur', 'abgelaufen' oder 'Algorithmus-Mismatch' ist
  • Test-JWTs während der Integration generieren: JWT im Browser mit einem Test-Schlüsselpaar ausstellen, keine Notwendigkeit, das Backend zu bitten, den Code vorübergehend zu ändern, um ein Token zu erstellen
  • PEM ↔ JWK-Konvertierung: der OIDC IdP hat Ihnen JWK gegeben, aber der Server benötigt PEM (oder umgekehrt) — vor Ort konvertieren, anstatt ein OpenSSL-Skript zu schreiben
  • 401 Unauthorized diagnostizieren: Ablauf, Algorithmus-zu-Gateway-Übereinstimmung, Schlüsselübereinstimmung und PEM-Formatierung nacheinander durchgehen
  • RS256 vs PS256 vergleichen: viele OIDC-Provider verwenden standardmäßig RS256, während AWS SigV4 PS256 bevorzugt — Algorithmen mit demselben RSA-Schlüsselpaar wechseln und Ergebnisse vergleichen
  • JWT-Interna lernen: Algorithmus ändern, Payload bearbeiten, Schlüssel im Browser austauschen und beobachten, wie die Signatur in Echtzeit bricht — viel schneller als das RFC lesen

Funktionen

  • Decodieren + Verifizieren + Generieren an einem Ort: Token einfügen, um Header/Payload/Signature zu trennen, Algorithmus und Schlüssel wechseln, um die Signatur zu verifizieren, Claims bearbeiten und neu signieren, um ein neues Token zu erzeugen — deckt die gesamte JWT-Fehlerbehebungskette ab
  • Alle 13 Algorithmen unterstützt: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — deckt OAuth 2.0, OIDC, JWS, API-Gateways und Enterprise-SSO ab
  • PEM- und JWK-Formate: RSA-, ECDSA- und Ed25519-Schlüssel akzeptieren PEM-Zeichenketten (mit -----BEGIN PUBLIC KEY----- Kopfzeilen) und JWK-JSON (kid/kty/n/e-Felder) — OIDC /.well-known/jwks.json Ausgabe direkt einfügen
  • Mehrere HMAC-Secret-Eingabeformen: rohe UTF-8-Zeichenkette, Hex-Bytes oder Base64/Base64URL-kodiertes Secret — mit einem Klick wechseln, damit 'sieht gleich aus, aber Signatur schlägt fehl' nie passiert
  • Automatische Schlüsselpaar-Generierung: RSA-2048, RSA-4096, P-256, P-384 und Ed25519 Schlüsselpaare im Browser generiert, in beiden PEM- und JWK-Formaten für sofortige Testnutzung präsentiert
  • Semantische Claims-Hervorhebung: exp / iat / nbf automatisch in menschenlesbare Zeit umgewandelt mit abgelaufen / noch-nicht-gültig / ausgestellt Status hervorgehoben; alg / typ / kid im Header einzeln beschriftet
  • 100% clientseitig, kein Upload: jede Analyse, Verifizierung und Signatur läuft über die native Web Crypto API des Browsers — Tokens, Schlüssel und Payload verlassen nie den Browser, entsprechend dem Sicherheitsprinzip 'niemals Produktions-Tokens in zufällige Online-Tools einfügen'
  • Ein-Klick-Kopieren: Header, Payload, Signature und das neu generierte Token sind jeweils unabhängig kopierbar für Dokumentation, Tickets und curl-Befehle

Anleitung

  1. Token einfügen oder eingeben: JWT-Zeichenkette in das Eingabefeld ablegen; das Tool teilt automatisch Header, Payload und Signature auf und gibt jedes als JSON formatiert aus
  2. Algorithmus auswählen: zwischen HS256 / RS256 / ES256 / PS256 / EdDSA wechseln; das Tool leitet aus Header.alg ab und markiert jeden Mismatch
  3. Schlüssel importieren: HMAC-Secret, PEM-Zeichenkette oder JWK-JSON einfügen; für asymmetrische Algorithmen auf 'Schlüsselpaar generieren' klicken, um sofort einen Test-Schlüssel zu erhalten
  4. Verifizieren oder neu signieren: im Decode-Modus mit öffentlichem Schlüssel verifizieren und '✅ Signatur gültig / ❌ Signatur ungültig' sehen; im Encode-Modus Claims bearbeiten und mit privatem Schlüssel signieren, um ein neues Token zu erzeugen

Häufig gestellte Fragen

Was sind die drei Teile eines JWT?

Die JWT-Zeichenkette besteht aus drei Segmenten `Header.Payload.Signature`, jedes Base64URL-kodiert. Der Header deklariert den Algorithmus (wie HS256, RS256) und den Token-Typ (typ: JWT); die Payload trägt Benutzer-Claims, häufige Felder sind sub (Benutzer-ID), iat (Ausstellungszeit), exp (Ablaufzeit), nbf (nicht vor), aud (Zielgruppe), iss (Aussteller); die Signature ist das Ergebnis der Signatur der ersten beiden Segmente mit einem Schlüssel, ihr Zweck ist 'Manipulationserkennung' nicht 'Abhörschutz'.

Kann ich die Payload nach dem Decodieren eines JWT bearbeiten?

Sie können sie ansehen und bearbeiten, aber **nicht fälschen**. Sobald Sie Header oder Payload ändern, wird die ursprüngliche Signature sofort ungültig und der Server wird sie ablehnen. Um das geänderte Token wieder verwendbar zu machen, müssen Sie es mit demselben Algorithmus und Schlüssel **neu signieren** — genau deshalb bietet dieses Tool 'Decodierung + Bearbeitung + Generierung' an einem Ort: decodieren, um einen Blick zu werfen, ändern, was Sie brauchen, und direkt ein neues Token für Tests generieren, ohne das Backend bitten zu müssen, den Code vorübergehend zu ändern, um eines auszustellen.

Was ist der Unterschied zwischen HS256, RS256, ES256, PS256 und EdDSA?

HS256 verwendet HMAC mit einem gemeinsamen Secret (symmetrisch), schnell, erfordert aber sichere Secret-Verwaltung; RS256 verwendet private/öffentliche RSA-Schlüssel (asymmetrisch), geeignet für Szenarien, bei denen Unterzeichner und Verifizierer getrennt sind; PS256 verwendet RSA-PSS-Padding, sicherer als RS256; ES256 verwendet P-256-elliptische Kurven, kürzere Signatur und bessere Leistung; EdDSA (normalerweise Ed25519) ist extrem schnell und deterministisch, empfohlen für neue Protokolle wie OAuth 2.1.

Warum zeigt mein JWT ungültige Signatur?

Der häufigste Grund ist, dass der Schlüssel, das Secret-Format, der Algorithmus oder die Base64URL-Kodierung nicht genau übereinstimmen. Ein zusätzliches Leerzeichen, ein PEM-Zeilenumbruch, Base64 mit Base64URL zu verwechseln, oder dass der Server RS256 verwendet, während das Tool HS256 verwendet, wird die Verifizierung fehlschlagen lassen. Dieses Tool verwenden, um Algorithmus und Secret-Format zu wechseln und eins nach dem anderen zu testen.

Dient derselbe RSA-Schlüssel zur Verifizierung von RS256 und PS256?

Nein. RS256 und PS256 verwenden unterschiedliche Padding-Schemata (PKCS1-v1_5 vs PSS). Obwohl der RSA-Schlüssel derselbe ist, können sie nicht kreuzweise verifiziert werden. Unterzeichner und Verifizierer müssen denselben Algorithmus verwenden.

Was ist ein alg:none-Angriff?

Ein Angreifer ändert den Header auf `{"alg":"none"}`, weist den Server an, die Signatur nicht zu verifizieren, oder ändert RS256 auf HS256 und verwendet den öffentlichen Schlüssel als HMAC-Secret, um den Server zu täuschen. Der Server muss eine Algorithmus-Whitelist verwenden (wie `algorithms: ['RS256']`) und niemals dem Header.alg des Tokens vertrauen, um den Verifizierungsalgorithmus zu entscheiden.

Wie konvertiere ich zwischen PEM und JWK?

PEM ist das klassische OpenSSL-Format mit BEGIN/END-Zeilen, häufig in traditionellen Setups; JWK ist JSON-Format, häufig in OAuth 2.0 / OIDC. Viele IdPs veröffentlichen öffentliche Schlüssel unter `/.well-known/jwks.json`. Dieses Tool akzeptiert beide Formate und kann zwischen ihnen wechseln.

Kann der Browser JWT-Signaturen direkt verifizieren?

Ja. Die Web Crypto API unterstützt HMAC, RSA, ECDSA, RSA-PSS und Ed25519 in modernen Browsern. Deshalb kann dieses Tool Signaturen direkt im Browser verifizieren, ohne das Token hochzuladen.

Wird mein Token an einen Server gesendet?

Nein. Analyse, Verifizierung und Signatur erfolgen im Browser. Das Network-Panel sollte keine Anfragen anzeigen, die das Token enthalten.

Kann ich sensible Daten in einem JWT speichern?

Nein. Die Payload ist standardmäßig lesbar (nur Base64URL-Decodierung erforderlich). Passwörter, nationale IDs, Kartennummern, API-Schlüssel, Access Tokens oder Refresh Tokens sollten niemals in ein Standard-JWT gelegt werden. Wenn Sie Vertraulichkeit benötigen, erwägen Sie JWE (JSON Web Encryption).

Was ist JWT Decoder, Verifizierer & Generator?

JWT (JSON Web Token) ist ein offener Standard, der von der IETF in RFC 7519 definiert wurde (RFC 7515 beschreibt die JWS-Signaturform, RFC 7516 beschreibt JWE-Verschlüsselung, RFC 7517 definiert JWK-Schlüssel) zur sicheren Übertragung 'behaupteter' Benutzerinformationen zwischen HTTP-Anfragen, OIDC-Flows und Microservice-Aufrufen. Eine Standard-JWT-Zeichenkette besteht aus drei Base64URL-kodierten Segmenten: Header (Algorithmus und Typ), Payload (Claims, die Benutzerdaten) und Signature (eine schlüsselbasierte Signatur über die ersten beiden). Die drei Segmente werden durch einen literalen Punkt `.` verbunden, z.B. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT ist keine Verschlüsselung.** Dies ist das häufigste Missverständnis. Die Payload ist standardmäßig Klartext — jeder kann sie mit Base64URL decodieren und den Inhalt lesen. JWT bietet **Manipulationserkennung**, nicht Vertraulichkeit: der Server signiert Header.Payload mit dem gemeinsamen Schlüssel erneut und vergleicht mit der Signature des Tokens. Wenn sie übereinstimmen, wurde das Token während der Übertragung nicht verändert. Dies ist die Metapher des 'Zugtickets mit Anti-Fälschungs-Stempel': dem Prüfer ist es wichtig, ob das Ticket echt ist, nicht ob der QR-Code unlesbar ist.

JWT teilt die Verantwortlichkeiten klar über 13 Algorithmen auf. **HMAC-Familie** (HS256/HS384/HS512) verwendet einen symmetrischen Schlüssel sowohl zum Signieren als auch zum Verifizieren, schnell und einfach, geeignet für einen einzelnen Dienst oder einen vertrauenswürdigen Cluster; das Secret muss mindestens die Digest-Länge haben (z.B. ≥ 32 Bytes für HS256). **RSA-Familie** (RS256/RS384/RS512) verwendet RSASSA-PKCS1-v1_5, das häufigste asymmetrische Schema — Unterzeichner halten den privaten Schlüssel, Verifizierer halten den öffentlichen Schlüssel. **RSA-PSS-Familie** (PS256/PS384/PS512) verwendet das neuere RSA-PSS-Padding mit stärkeren Sicherheitsgarantien, bevorzugt von AWS SigV4 und modernen OIDC-Identitätsanbietern. **ECDSA-Familie** (ES256/ES384/ES512) verwendet elliptische Kurven (P-256/P-384/P-521 jeweils) mit kürzeren Signaturen und besserer Leistung. **EdDSA** (hauptsächlich Ed25519) ist extrem schnell und deterministisch (gleiche Nachricht + gleicher Schlüssel = gleiche Signatur jedes Mal) und ist der empfohlene Algorithmus in OAuth 2.1 und neuen Protokollen.

Sicherheit ist der Punkt, an dem JWT in der Produktion scheitert. Das OWASP JWT Cheat Sheet nennt mindestens vier harte Regeln: (1) niemals Passwörter, nationale IDs, Kartennummern oder API-Schlüssel als Klartext in die Payload legen; (2) der Server darf **niemals dem alg-Feld** vertrauen, das im Token-Header deklariert ist — er muss mit einem hartcodierten Algorithmus verifizieren, sonst umgeht ein Angreifer, der den Header auf `alg: none` umschreibt, alles (dies ist die Wurzel historischer CVEs wie CVE-2015-9235); (3) HMAC-Secrets müssen zufällig und mindestens 32 Bytes lang sein, niemals kurze Zeichenketten; (4) Verifizierung ist mehr als Signaturprüfungen — Sie müssen auch `exp` (Ablauf), `nbf` (nicht vor), `iss` (Aussteller) und `aud` (Zielgruppe) validieren. Dieses Tool hebt jeden dieser Claims in der UI hervor, sodass Sie auf einen Blick erkennen können, ob ein Fehler ein Signaturproblem, ein Timing-Problem oder ein Claims-Problem ist.

JWT ist kein Ersatz für Sessions. Sessions speichern den Benutzerstatus auf dem Server (Redis oder einer Datenbank); JWT packt den Status in das Token. Microservice-Architekturen, zustandslose APIs, mobile Clients und CORS-lastige Setups profitieren von JWT; traditionelle Unternehmenssysteme und Flows, die sofortige Widerrufung erfordern (z.B. 'diesen Benutzer jetzt rauswerfen'), werden immer noch besser von Sessions bedient. Dieses Tool deckt sowohl reines JWT-Debugging als auch die Token-Analyse / Signatur-Verifizierung / Payload-Bearbeitungsschritte einer Session-zu-JWT-Migration ab.

Code Examples

50 Zeilen Node.js: handgeschriebene HS256-Signatur und -Verifizierung

javascript

Destilliert JWTs Kernmechanismus: Header und Payload in Base64URL kodieren, dann HMAC-SHA256 auf die `header.payload`-Zeichenkette anwenden. In der Produktion eine Bibliothek wie jsonwebtoken oder jose verwenden — dieses Snippet existiert, um Signaturfehler debuggbar zu machen.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-seitig: Web Crypto API für HMAC-Signatur

html

Die Kernidee des Frontends dieses Tools: die native crypto.subtle des Browsers für HMAC, RSA, ECDSA, RSA-PSS und Ed25519-Verifizierung verwenden — keine Drittanbieter-Bibliothek erforderlich. Dies in jede HTML-Seite einfügen, um HS256-Tokens zu erstellen.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: RS256 mit jose verifizieren (der richtige Weg)

javascript

In der Produktion eine ausgereifte Bibliothek wie jose, jsonwebtoken oder PyJWT verwenden — niemals selbst implementieren. Dieses Snippet zeigt, wie jose ein RS256-Token verifiziert und bei Fehlern den Fehlergrund ausgibt (Algorithmus-Mismatch, falsche Signatur, abgelaufen, kid nicht gefunden usw.).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // kritisch: Algorithmus-Whitelist blockiert alg:none und HS256-Substitutionsangriffe
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // häufig: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: Token mit PyJWT analysieren und Claims ausgeben

python

Die häufigste Methode, JWT auf der Python-Seite zu debuggen. PyJWTs decode() validiert standardmäßig exp / nbf / iat und gibt das Ergebnis als einfaches dict zurück.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Analysieren (keine Signaturprüfung, nur Header und Payload ansehen)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Vollständige Verifizierung
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalSymmetrischer Schlüsselalgorithmus. Dasselbe Secret signiert und verifiziert, einfach und schnell, geeignet für Dienst-Cluster innerhalb einer vertrauenswürdigen Grenze. Secret muss mindestens 32 zufällige Bytes sein.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIDer häufigste asymmetrische Algorithmus. Mit privatem Schlüssel signieren, mit öffentlichem Schlüssel verifizieren. Standard für die meisten OIDC-IdPs, API-Gateways und Enterprise-SSO.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS ist das aktualisierte, sicherere Ersatz für RS256. AWS SigV4, AWS Cognito und moderne OIDC-Anbieter bevorzugen es tendenziell. saltLength muss explizit angegeben werden.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIElliptische-Kurven-Signaturen. Kurze Signaturen (ES256 ist nur 64 Bytes), schnelle Leistung, kleinere JWTs. Apple Sign in with Apple verwendet standardmäßig ES256.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APINext-Generation-Hochleistungs-Signaturalgorithmus. Deterministische Signaturen (gleiche Nachricht + gleicher Schlüssel erzeugen immer dasselbe Ergebnis), kein Nonce-Reuse-Risiko, von OAuth 2.1 empfohlen.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL):  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload(Base64URL):  eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature:           kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Header decodiert:
  {
    "alg": "HS256",
    "typ": "JWT"
  }

Payload decodiert:
  {
    "sub": "1234567890",
    "name": "Jane Doe",
    "iat": 1716239022        // 2024-05-20 14:23:42 UTC
  }

Privacy & Security

Diese JWT-Werkbank läuft zu 100% in Ihrem Browser, unterstützt durch die native Web Crypto API des Browsers. Das Token, das Sie einfügen, der Header, die Payload, die Signature, das HMAC-Secret, alle RSA/ECDSA-Privatschlüssel, alle generierten Schlüsselpaare und jede Signatur/Verifizierungsberechnung bleiben auf Ihrem Gerät — sie reisen niemals zu einem Server, werden niemals protokolliert, niemals analysiert und niemals zwischengespeichert. Die Seite kann nach dem Laden offline verwendet werden. Best Practice: niemals langlebige Produktions-Tokens oder Produktions-Privatschlüssel in ein Online-Tool einfügen, einschließlich dieses. Dieses Tool ist geeignet zum Debuggen, Integrationstesten, Lernen und Erstellen von Test-Tokens — Produktions-Secrets und Privatschlüssel sollten in einer kontrollierten, lokalen Umgebung verarbeitet werden.

Authoritative References

Troubleshooting

Ungültige Signatur: 'signature is invalid'

Das Token und der Verifizierungsschlüssel stimmen nicht überein. Die üblichen Ursachen: (1) der Schlüssel des Servers und der Schlüssel, den Sie in das Tool eingefügt haben, sind unterschiedlich (am häufigsten); (2) der Schlüssel enthält unsichtbare Zeichen (abschließendes Leerzeichen, Zeilenumbruch, Zero-Width-Zeichen); (3) Base64 und Base64URL werden gemischt; (4) der falsche Algorithmus ist ausgewählt (Header sagt HS256, Server verifiziert als RS256, oder umgekehrt). Zuerst prüfen, ob der Schlüssel Byte für Byte übereinstimmt: auf abschließende Zeilenumbrüche beim PEM, abschließende Leerzeichen beim HMAC-Secret und JWK-`k`-Werte achten, die möglicherweise falsch URL-dekodiert wurden. Bestätigen, dass der Algorithmus im Tool mit dem Header.alg des Tokens übereinstimmt. Die Decode-plus-Verify-Funktion dieses Tools verwenden, um den genauen Fehler zu reproduzieren und zu bestätigen, dass er zwischen 'Decodierung erfolgreich' und 'Verifizierung fehlgeschlagen' auftritt.

HTTP 401 Unauthorized: Token abgelaufen oder iat in der Zukunft

Signaturverifizierung bestanden, aber `exp` liegt in der Vergangenheit (Token abgelaufen), `nbf` liegt noch in der Zukunft (nicht vor), oder `iat` ist später als die aktuelle Serverzeit (oft aufgrund von Uhrzeitabweichung). Ein weiterer häufiger Fall ist ein nicht übereinstimmendes `aud` (Zielgruppe): das Token wurde für App A ausgestellt, aber von App B validiert. Den hervorgehobenen Claims-Bereich dieses Tools verwenden, um den Status von exp / nbf / iat auf einen Blick zu erkennen. Rot exp = abgelaufen, bitte neu ausstellen. Rot nbf = noch nicht gültig, prüfen, ob iat eine zukünftige Zeit ist. Rot aud = falsche Zielgruppe, prüfen, dass der Server die richtige Zielgruppe konfiguriert hat.

PEM- oder JWK-Importfehler

PEM hat zusätzliche Leerzeilen oder fehlende Kopf-/Fußzeilen-Markierungen (`-----BEGIN PUBLIC KEY-----`); JWK fehlen erforderliche Felder (`kty` / `n` / `e` / `kid`); JWK-`k`-Wert fehlt Base64URL-Padding (muss mit `=` aufgefüllt oder strikt `=`-entfernt sein); ein RSA-Privatschlüssel wird als öffentlicher Schlüssel importiert; ein Ed25519-Privatschlüssel (32-Byte-Seed) wird als 64 Bytes angegeben. Ein Standard-PKIX-PEM mit `openssl rsa -in key.pem -pubout -outform PEM` oder `openssl ec -in key.pem -pubout` erneut exportieren; für JWK die Roh-Ausgabe des OIDC Discovery `/.well-known/jwks.json`-Endpunkts verwenden, anstatt die Kodierung manuell zu erstellen. Dieses Tool erkennt automatisch PEM-Kopfzeilen, fehlendes Padding und fehlende JWK-Felder und zeigt einen Hinweis an.

RS256 vs PS256 sprachübergreifende Signaturfehler

RS256 verwendet RSASSA-PKCS1-v1_5, PS256 verwendet RSA-PSS. Die beiden **können nicht kreuzweise verifiziert werden** — ein mit RS256 von einem gegebenen RSA-Schlüssel signiertes Token wird immer die PS256-Verifizierung fehlschlagen lassen, und die Signatur kann sich in der Länge um einige Bytes unterscheiden. Sicherstellen, dass Unterzeichner und Verifizierer denselben Algorithmus verwenden. AWS SigV4 verwendet PS256, die meisten OIDC-IdPs verwenden RS256. RSA-PSS hat auch einen `saltLength`-Parameter — OpenSSL standardmäßig 32, jose 32, Gos `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` ist das richtige Äquivalent. Dies vor sprachübergreifenden Integrationstests festlegen.

alg:none-Angriff und HS256-Schlüsselaustausch-Angriff

Der Server wählt einen Verifizierungsalgorithmus basierend auf dem im Token-Header deklarierten Algorithmus. Ein Angreifer schreibt den Header auf `alg: none` (keine Signatur) um oder schreibt ein RS256-Token auf HS256 um (verwendet den öffentlichen Schlüssel, als wäre er ein gemeinsames HMAC-Secret) und umgeht die Verifizierung. Historische CVEs wie CVE-2015-9235 (jsonwebtoken) und CVE-2022-23529 (mehrere Node-Bibliotheken) gehen auf dieses Muster zurück. Der Server muss eine Algorithmus-Whitelist erzwingen — zum Beispiel `algorithms: ['RS256']` — und darf dem Token niemals sagen, welchen Algorithmus er verwenden soll. Die UI dieses Tools zeigt sowohl Header.alg als auch den tatsächlich ausgewählten Algorithmus an und markiert Mismatches: das ist selbst eine Live-Demo von 'der Client darf Header.alg nicht vertrauen'.