JWT erstellen und dekodieren: Token online bauen und prüfen

Header und Payload eines JWT dekodieren oder ein Test-Token signieren, direkt im Browser: HS256, RS256, ES256, ohne Secret an einen Drittserver zu senden.

04.10.2026

15 Min. Lektüre

Teilen Sie diesen Artikel:

JWT

Authentifizierung

Tokens

Sicherheit

Anleitung

Ein JWT kann jeder lesen: dekodieren zum Prüfen, signieren zum Testen, verifizieren zum Vertrauen

Ein JSON Web Token wirkt undurchsichtig, doch seine ersten beiden Segmente sind gewöhnliches JSON in Base64URL: Wer das Token besitzt, kann es lesen. Genau das brauchen Sie, wenn eine API 401 antwortet und Sie wissen wollen, was das Token behauptet. Der JWT-Decoder online von FastMinify dekodiert Header und Payload, sobald Sie das Token einfügen, und der JWT-Encoder signiert ein Token aus bearbeitbarem Header- und Payload-JSON, live und ohne Absenden-Schaltfläche. Beide laufen in Ihrem Browser: Token, Claims und Secret werden nirgendwohin gesendet. Dekodieren ist jedoch nicht Verifizieren. Jeder kann "role": "admin" in eine Payload schreiben, deshalb beweist ein dekodiertes Token nichts über seinen Aussteller. Eine Signatur gegen die öffentlichen Schlüssel eines Ausstellers, die Zielgruppe (aud), den Aussteller (iss) und den Ablauf zu prüfen, ist die Aufgabe von jwt-verify, das ein eingefügtes JWKS entgegennimmt; inspect-jwks zeigt, was in einem solchen Schlüsselsatz steckt. Dieser Leitfaden erklärt den Aufbau eines JWT, wie Sie einen 401 oder 403 mit einem dekodierten Token debuggen, welche Fehler aus einem Testwerkzeug eine Sicherheitslücke machen und wie dieselben Operationen in Node mit der Bibliothek jose aussehen. Die Werkzeuge liegen im Hub für Sicherheits-Tools.

Dekodieren: Fügen Sie das kompakte Token ein, und Header und Payload erscheinen als formatiertes JSON. Ein JWT hat genau drei durch Punkte getrennte Teile; die Signatur darf nur leer sein, wenn der Header alg=none angibt

Kodieren: Signieren in Echtzeit, ohne Absenden-Schaltfläche. Algorithmen: none, HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 und EdDSA (nur Ed25519)

Beim Kodieren wird iat immer auf die aktuelle Zeit gesetzt. Das Menü Ablauf (Keins, 15 Minuten, 1 Stunde, 24 Stunden) überschreibt exp relativ zu iat; „Keins“ lässt Ihre Payload unverändert

HMAC-Tokens brauchen ein Secret (optional als Base64URL-Bytes gelesen); RSA, ECDSA und EdDSA brauchen einen privaten Schlüssel als PEM (PKCS#8) oder JWK

Optionale Signaturprüfung neben dem Decoder, mit Secret oder öffentlichem Schlüssel: Sie prüft nur die Signatur, nie exp, aud oder iss

Alles bleibt im Tab: Kein Token, Claim oder Schlüssel wird an einen Server gesendet

Kodieren, dekodieren oder verifizieren: Welches Werkzeug beantwortet welche Frage

Passende Einsätze

Decoder und Encoder decken alles ab, was kein Vertrauen in einen Aussteller herstellen muss.

Die Claims eines aus dem Netzwerk-Tab kopierten Tokens lesen (exp, aud, scope), bevor Sie eine API-Route verdächtigen

Ein Fixture-Token für einen Integrationstest bauen: HS256, ein Wegwerf-Secret, 15 Minuten oder 1 Stunde Ablauf

Ein Token mit einem bestimmten Header (alg, kid) erzeugen, um zu sehen, wie Ihre API es ablehnt

Prüfen, ob ein HS256-Token wirklich mit dem Secret signiert wurde, das Sie vermuten: Secret neben dem Decoder einfügen

Das kompakte Format lehren oder lernen: ein Zeichen der Payload ändern und zusehen, wie sich das Signatursegment ändert

Was woanders hingehört

Einem Token zu vertrauen braucht Schlüssel, Claims und eine Richtlinie, nicht nur eine lesbare Payload. Übergeben Sie an jwt-verify, inspect-jwks oder an Ihren eigenen Code.

Ein Token gegen die öffentlichen Schlüssel eines Identity-Providers verifizieren: JWKS in <a href="/de/jwt-verify" class="text-primary hover:underline">jwt-verify</a> einfügen, das Signatur, Ablauf, Zielgruppe und Aussteller prüft, mit einer Zeittoleranz von 0, 60 oder 300 Sekunden. Es lädt nie ein JWKS aus dem Netz

Sehen, welche Schlüssel ein JWKS enthält (kid, kty, alg), bevor Sie ein „key not found“ debuggen: <a href="/de/inspect-jwks" class="text-primary hover:underline">inspect-jwks</a>

Tokens in der Produktion ausstellen und validieren: eine gepflegte Bibliothek auf dem Server, mit festgelegtem Algorithmus. Nie eine Webseite

Eine Sitzung widerrufen: Ein signiertes JWT bleibt von sich aus bis exp gültig. Das ist eine Entwurfsfrage Ihres Auth-Flows und liegt außerhalb dessen, was ein Decoder sagen kann

Passwörter von Nutzern speichern: ein langsamer, gesalzener Hash, kein JWT. Siehe den <a href="/de/blog/sicheres-passwort-online-generieren" class="text-primary hover:underline">Leitfaden zum Passwort-Generator</a> und das <a href="/de/bcrypt-hash" class="text-primary hover:underline">bcrypt-Werkzeug</a>

Einen 401 oder 403 mit einem dekodierten Token debuggen

401: abgelaufen, noch nicht gültig oder beschädigt

Fügen Sie das Token in den Decoder ein und lesen Sie die Zeit-Claims, bevor Sie die API anfassen. exp, nbf und iat sind NumericDate-Werte: Sekunden seit dem 1. Januar 1970 UTC (RFC 7519).

Ein 13-stelliges exp sind Millisekunden, keine Sekunden: Der Erzeuger liegt falsch, und viele Bibliotheken lesen es als Datum in einigen zehntausend Jahren

Rechnen Sie den Wert in einer Konsole um: <code>new Date(exp * 1000).toISOString()</code>. Der Decoder zeigt die Rohzahl und rechnet sie nicht für Sie um

Ziehen Sie iat von exp ab: Das Ergebnis ist die Lebensdauer des Tokens in Sekunden (3600 für eine Stunde). Eine Dauer von 0 oder eine negative Zahl deutet auf eine falsche Konfiguration des Ausstellers hin

Ein nbf in der Zukunft oder ein iat, das der Uhr der API vorausgeht, bedeutet Zeitabweichung zwischen Aussteller und API: Server akzeptieren meist eine kleine Toleranz, und mit jwt-verify können Sie 0, 60 und 300 Sekunden testen

Fügen Sie nur das kompakte Token ein. Ein vorangestelltes <code>Bearer </code>, ein Zeilenumbruch oder ein von einem Log abgeschnittenes Zeichen lässt den Decoder ein ungültiges Token oder eine falsche Teilezahl melden

401 bei einem Token, das gut aussieht: Algorithmus, Schlüssel und Signatur

Stimmen die Claims und die API lehnt trotzdem ab, liegt das Problem im Header oder in der Signatur.

alg im Header muss der sein, den die API erwartet. Eine auf RS256 festgelegte API lehnt ein HS256-Token ab und umgekehrt

kid benennt einen Schlüssel im Schlüsselsatz des Ausstellers: Öffnen Sie das JWKS in <a href="/de/inspect-jwks" class="text-primary hover:underline">inspect-jwks</a> und prüfen Sie, ob er existiert und ob alg und kty passen

Fügen Sie das HMAC-Secret neben dem Decoder ein: „Signatur ungültig“ bei einem scheinbar richtigen Secret bedeutet meist, dass die Base64URL-Option falsch steht (siehe unten) oder das Token unterwegs verändert wurde

Ein Token mit fünf durch Punkte getrennten Teilen ist ein verschlüsseltes JWE, kein signiertes JWT. Der Decoder lehnt es ab, da er genau drei Teile erwartet

Ein aus einem Cookie oder Header kopiertes Token kann durch ein Größenlimit abgeschnitten sein: Ein fehlendes letztes Segment ist das typische Symptom

403: authentifiziert, aber nicht berechtigt

Ein 403 heißt, das Token wurde akzeptiert und die Autorisierung hat Nein gesagt. Die Payload verrät meist, warum.

aud muss die Kennung enthalten, die die API erwartet, und iss muss zum Aussteller passen, dem sie vertraut. Ein für eine andere API oder einen anderen Tenant ausgestelltes Token scheitert hier

Berechtigungen stehen je nach Anbieter unter verschiedenen Claim-Namen: scope, scp, roles oder permissions. Prüfen Sie den, den Ihre API tatsächlich liest

Ein scope-String ist durch Leerzeichen getrennt (<code>"orders:read orders:write"</code>), Rollen sind dagegen oft ein Array: Code, der das eine wie das andere zerlegt, verweigert still alles

sub bezeichnet den Nutzer, nicht die Anwendung: Ein Service-zu-Service-Token kann dort eine Client-ID tragen

Eine frisch geänderte Berechtigung steckt nicht in einem vor der Änderung ausgestellten Token: Dekodieren Sie ein neues Token, bevor Sie die Regel für falsch halten

Vier Fehler, die aus einem Testwerkzeug eine Sicherheitslücke machen

Ein dekodiertes Token als vertrauenswürdig behandeln

Ein Decoder zeigt, was ein Token behauptet, nicht, wer es geschrieben hat. Die Payload ist nicht geschützt: Wer das Token hat oder eines bauen kann, kann jeden beliebigen Claim hineinschreiben. Der Encoder kann sogar ein ungesichertes Token mit alg=none erzeugen, dessen Signatursegment leer ist: Die Werkzeuge kennzeichnen es als „Unsigniertes JWT (alg=none)“, und kein Verifizierer sollte es je akzeptieren. RFC 8725 (Best Current Practices für JWT) verlangt von Servern, nur erwartete Algorithmen zu akzeptieren und nie das Token wählen zu lassen. Algorithm Confusion ist der klassische Fehler: Ein Token, das HS256 angibt und mit dem öffentlichen Schlüssel eines RS256-Dienstes signiert ist, passiert einen Verifizierer, der alg aus dem Header liest und den öffentlichen Schlüssel als HMAC-Secret benutzt.

<code>"role": "admin"</code> in einer dekodierten Payload als Beweis lesen, dass der Nutzer Admin ist

Jeden alg akzeptieren, den der Token-Header angibt, auch none

Autorisierung in einem Frontend aus Claims entscheiden, die nie verifiziert wurden

Das „Signatur verifiziert“ eines Decoders als Ersatz für Prüfungen von Zielgruppe, Aussteller und Ablauf nehmen

Dekodieren Sie zum Debuggen. In der API verifizieren Sie mit im Code festgelegtem Algorithmus und Schlüssel und prüfen dann aud, iss und exp.

Glauben, die Payload sei geheim

Base64URL ist eine Kodierung, keine Verschlüsselung: Der Base64-Leitfaden erklärt den Unterschied. Ein signiertes JWT (JWS) garantiert nur Integrität, die gesamte Payload ist also lesbar. Verschlüsselte Tokens gibt es (JWE, RFC 7516, fünf statt drei Teile), doch der Decoder hier verarbeitet nur signierte Tokens. Ein Token ist außerdem ein Zugangsnachweis: Wer es besitzt, kann es bis exp verwenden. Dieses Werkzeug behält es in Ihrem Tab, aber eine Bildschirmfreigabe, ein geteilter Screenshot oder ein Ticket mit eingefügtem Token geben es trotzdem preis.

Ein Passwort, eine Kartennummer oder eine Privatadresse in einen Claim schreiben

Ein noch gültiges Produktions-Token in ein Ticket, einen Chat oder eine fremde Website einfügen

Den vollständigen Authorization-Header loggen

Annehmen, ein unlesbar aussehendes Token sei ein geschütztes

Wer ein noch gültiges Token aus einem Log oder einem Screenshot kopiert, kann die API bis exp als dieser Nutzer aufrufen.

Schwache oder falsch gelesene HMAC-Secrets

HS256 signiert mit einem gemeinsamen Secret, und RFC 7518 verlangt einen Schlüssel, der mindestens so lang ist wie die Hash-Ausgabe: 256 Bit für HS256, 384 für HS384, 512 für HS512. Ist Ihr Secret kürzer, zeigt der Encoder seine Bitzahl im Vergleich zum empfohlenen Minimum an. Diese Zahl ist die Schlüssellänge, nicht seine Zufälligkeit: Ein deutscher Satz mit 32 Zeichen ist 256 Bit lang und trotzdem erratbar. Wer ein einziges Token besitzt, kann Kandidaten-Secrets offline gegen dessen Signatur testen, ohne Ihre API je zu berühren. Ziehen Sie das Secret zufällig, zum Beispiel mit dem Passwort-Generator (siehe den Passwort-Leitfaden): Etwa 41 Zeichen aus seinem Standardzeichensatz mit 82 Zeichen tragen 256 Bit Entropie. Die Base64URL-Option ändert die verwendeten Bytes: Angekreuzt wird die Secret-Zeichenkette als Base64URL dekodiert und ihre Bytes sind der Schlüssel; nicht angekreuzt sind die Zeichen selbst der Schlüssel. Derselbe Text mit der falschen Einstellung ergibt eine andere Signatur.

<code>secret</code>, <code>changeme</code> oder den Projektnamen als HS256-Schlüssel verwenden

„256 Bit lang“ als „256 Bit Entropie“ lesen

Mit aktivierter Base64URL-Option signieren und mit deaktivierter verifizieren oder umgekehrt

Ein HMAC-Secret zwischen Diensten teilen, die nicht alle Tokens ausstellen können sollten

Erzeugen Sie das Secret zufällig, halten Sie es in der Umgebung und bevorzugen Sie einen asymmetrischen Algorithmus, wenn mehrere Dienste nur verifizieren sollen.

Ein Test-Token den Test verlassen lassen

Der Encoder ist für Fixtures und Debugging gebaut. Er setzt iat auf jetzt, kann die Signatur ganz weglassen, und die geladenen Beispiele nutzen Wegwerf-Secrets. Ein hier mit einem Demo-Secret signiertes Token darf in einer echten Umgebung nie akzeptiert werden, und ein echtes Signatur-Secret darf nie in eine Datei geraten, die Sie danach committen. Ist es schon passiert, tauschen Sie es aus und scannen Sie Ihren Diff vor dem Commit mit dem Secrets-Scanner.

Ein langlebiges Test-Token committen, dessen Secret auch im Staging funktioniert

Eine alg=none-Abkürzung „für lokale Entwicklung“ hinter einem Flag lassen, das in die Produktion geht

Dasselbe Signatur-Secret in Entwicklung, Staging und Produktion verwenden

Vergessen, dass ein auf 24 Stunden gesetztes exp in einer Fixture 24 Stunden lang ein Zugangsnachweis bleibt

Geben Sie jeder Umgebung ein eigenes Secret, halten Sie Fixtures kurzlebig und lassen Sie den Verifizierer überall alg=none ablehnen.

Aufbau eines JWT: drei Base64URL-Segmente und was jedes sagt

header.payload.signature

Die kompakte Form besteht aus drei Base64URL-Segmenten, verbunden durch Punkte. So reist ein JWT in einem Authorization: Bearer-Header.

Header: ein JSON-Objekt wie <code>{"alg":"HS256","typ":"JWT"}</code>, das zu <code>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9</code> kodiert wird. Er nennt den Signaturalgorithmus und bei asymmetrischen Schlüsseln meist eine kid.

Payload: ein JSON-Objekt aus Claims, etwa über wen das Token spricht, wer es ausgestellt hat, wer es nutzen darf und bis wann.

Signatur: berechnet über <code>base64url(header) + "." + base64url(payload)</code> mit dem Algorithmus aus dem Header. Bei HS256 ist das HMAC-SHA-256 mit dem gemeinsamen Secret.

Base64URL (RFC 7515) nutzt <code>-</code> und <code>_</code> statt <code>+</code> und <code>/</code> und lässt das Auffüllzeichen <code>=</code> weg, sodass ein JWT unverändert in einer URL oder einem Header stehen kann.

Ändern Sie ein Zeichen in Header oder Payload, passt die Signatur nicht mehr: Das ist der einzige Schutz, den das Format bietet.

Die Claims, die Sie zuerst lesen

Sieben registrierte Claims (RFC 7519) decken die meisten Debugging-Sitzungen ab. Alle sind in der Spezifikation optional, eine API darf also mehr verlangen als der Standard.

iss: der Aussteller, meist eine URL. sub: das Subjekt, meist eine Nutzer-ID. aud: die Zielgruppe, ein String oder ein Array.

exp: der Ablauf, nbf: nicht vor, iat: ausgestellt um. Alle drei sind NumericDate: Sekunden seit dem 1. Januar 1970 UTC.

jti: eine eindeutige Token-Kennung, nützlich, wenn ein Server eine Sperrliste führt.

Beispiel: iat 1790000000 ist 2026-09-21T14:13:20Z, und exp 1790003600 eine Stunde später, 15:13:20Z.

Eigene Claims wie scope, roles oder tenant sind anbieterspezifisch. Die Spezifikation definiert sie nicht.

Algorithmenfamilien: Was signiert und was verifiziert

Der Wert von alg entscheidet, wer ein Token ausstellen und wer es nur prüfen kann.

HS256, HS384, HS512: Ein gemeinsames Secret signiert und verifiziert, also kann jeder Verifizierer auch Tokens fälschen.

RS256/384/512 und PS256/384/512 (RSA), ES256/384/512 (ECDSA), EdDSA (Ed25519): Ein privater Schlüssel signiert, ein öffentlicher verifiziert. Die öffentlichen Schlüssel veröffentlicht ein Identity-Provider als JWKS.

Der Encoder unterstützt alle, dazu none, das ein auf einen Punkt endendes Token ganz ohne Signatur erzeugt.

EdDSA heißt hier nur Ed25519, der dokumentierte Umfang des Werkzeugs.

Wählen Sie einen asymmetrischen Algorithmus, wenn mehrere Dienste Tokens verifizieren müssen, die nur ein Dienst ausstellen darf.

Dekodieren und kodieren in den Werkzeugen: die Anleitung

Ein Token mit jwt-decode prüfen

Der JWT-Decoder hat keine Schaltfläche: Das Dekodieren läuft beim Einfügen oder Bearbeiten nach einer kurzen Pause. Der Editor startet leer; „Beispiel laden“ oder die Wahl eines Algorithmus lädt ein Demo-Token.

Das kompakte Token einfügen

Nur die drei Segmente, ohne das Präfix Bearer . Leerzeichen am Anfang und Ende werden ignoriert.

Header und Payload lesen

Beide erscheinen als formatiertes JSON in einem eigenen Bereich, neben der rohen Signatur. Prüfen Sie zuerst alg, kid, exp, aud und iss.

Optional die Signatur prüfen

Fügen Sie das HMAC-Secret ein oder bei asymmetrischen Algorithmen einen öffentlichen Schlüssel als PEM oder JWK. Das Ergebnis lautet „Signatur verifiziert“ oder „Signatur ungültig“ und betrifft nur die Signatur.

Einen Fehler lesen, falls es einen gibt

Der Decoder meldet eine falsche Teilezahl, ein leeres Segment, eine fehlende Signatur (nur bei alg=none erlaubt) oder ein Segment, das kein Base64URL-JSON ist.

Ein Test-Token mit jwt-encode bauen

Der JWT-Encoder signiert beim Tippen. Das Token erscheint, sobald Header, Payload und Schlüssel gültig sind.

Den Algorithmus wählen

Nutzen Sie die Werkzeugleiste oder ändern Sie alg im Header-JSON. Ein fehlender oder nicht unterstützter alg wird als ungültiger Header gemeldet.

Die Claims schreiben

Ein JSON-Objekt. iat wird bei jedem Kodieren mit der aktuellen Zeit überschrieben, ein altes iat lässt sich also nicht festschreiben.

Bei Bedarf einen Ablauf setzen

Das Menü Ablauf (15 Minuten, 1 Stunde, 24 Stunden) überschreibt jedes exp im JSON. „Keins“ lässt Ihre Payload unverändert.

Den Schlüssel angeben

Ein Secret für HMAC oder einen privaten Schlüssel als PEM (PKCS#8) oder JWK für RSA, ECDSA und EdDSA. Ein Secret unter der empfohlenen Länge zeigt eine Warnung mit seiner Größe in Bit.

Das Token kopieren und prüfen

Fügen Sie es in den Decoder ein, um zu sehen, was Sie erzeugt haben, danach in jwt-verify, um eine echte Verifizierungsrichtlinie zu testen.

Was die Werkzeuge nicht tun

Einige Grenzen, die Sie kennen sollten, bevor Sie sich für einen bestimmten Zweck darauf verlassen.

Keine Validierung von exp, nbf, aud oder iss in Decoder oder Encoder: Das übernimmt jwt-verify

Keine Umrechnung von Zeitstempeln in Datumsangaben: Der Decoder zeigt die rohen Sekunden

Kein Abruf eines JWKS aus dem Netz, nirgends: Schlüssel werden eingefügt

Keine verschlüsselten Tokens (JWE): nur signierte mit drei Teilen

EdDSA gilt nur für Ed25519

Ein hier signiertes Token ist eine Fixture, keine Produktionsauthentifizierung

Dieselben Operationen in Ihrem eigenen Code

Node: dekodieren ohne zu verifizieren

Das Dekodieren braucht keine Bibliothek: an den Punkten teilen und jedes Segment als Base64URL lesen. Genau das macht der Decoder, mit derselben Grenze: Nichts wird geprüft.

Einfaches Beispiel

// Decode WITHOUT verifying: read the claims, trust nothing.
function decodeJwt(token) {
  const [h, p, s] = token.split('.')
  if (!h || !p || !s) throw new Error('Erwartet wird header.payload.signature')
  const json = (part) => JSON.parse(Buffer.from(part, 'base64url').toString('utf8'))
  return { header: json(h), payload: json(p) }
}

const token =
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwic2NvcGUiOiJvcmRlcnM6cmVhZCIsImlzcyI6Imh0dHBzOi8vYXV0aC5leGFtcGxlLmNvbSIsImF1ZCI6Im9yZGVycy1hcGkiLCJpYXQiOjE3OTAwMDAwMDAsImV4cCI6MTc5MDAwMzYwMH0.S7icJbfp1NQ88Pkyf9HYZ6tl-jkLgOCOzxFDSCKFLvE'

const { header, payload } = decodeJwt(token)
console.log(header.alg) // HS256
console.log(new Date(payload.exp * 1000).toISOString()) // 2026-09-21T15:13:20.000Z
// Fügen Sie dieses Token in jwt-decode ein; mit dem Secret "demo-secret-for-docs-only-0123456789abcdef" zeigt es „Signatur verifiziert“

Mit jose signieren

Die Bibliothek jose signiert ein kompaktes JWT und setzt die registrierten Claims für Sie. Anders als der Encoder hier nutzt setIssuedAt() die echte Uhr, wie es in der Produktion sein soll.

Einfaches Beispiel

import { SignJWT } from 'jose'

// HS256: key of at least 32 bytes (256 bits), read from the environment
const secret = new TextEncoder().encode(process.env.JWT_SECRET)

const token = await new SignJWT({ scope: 'orders:read' })
  .setProtectedHeader({ alg: 'HS256', typ: 'JWT' })
  .setSubject('user_42')
  .setIssuer('https://auth.example.com')
  .setAudience('orders-api')
  .setIssuedAt()
  .setExpirationTime('1h')
  .sign(secret)

Mit festgelegtem Algorithmus verifizieren

Bei der Verifizierung entsteht Vertrauen: Legen Sie Algorithmus, Aussteller und Zielgruppe fest und erlauben Sie eine kleine Zeittoleranz.

Einfaches Beispiel

import { jwtVerify } from 'jose'

try {
  const { payload } = await jwtVerify(token, secret, {
    algorithms: ['HS256'], // Akzeptierten Algorithmus fest vorgeben: nie aus dem Token-Header übernehmen
    issuer: 'https://auth.example.com',
    audience: 'orders-api',
    clockTolerance: 60, // Sekunden Toleranz für Zeitabweichungen zwischen Aussteller und API
  })
  console.log(payload.sub)
} catch (err) {
  // ERR_JWT_EXPIRED, ERR_JWS_SIGNATURE_VERIFICATION_FAILED, ERR_JWT_CLAIM_VALIDATION_FAILED …
  console.error(err.code)
}

FastMinify jwt-decode und jwt-encode

Nichts zu installieren, nichts gesendet: Decoder und Encoder decken das Lesen von Claims, das Bauen von Fixtures und das Prüfen einer Signatur ab, für die Sie den Schlüssel besitzen. Die Kompromisse: keine Claim-Validierung, keine Zeitstempel-Umrechnung, kein JWE, EdDSA auf Ed25519 beschränkt. Für eine echte Vertrauensentscheidung nutzen Sie eine Verifizierungsbibliothek auf dem Server oder fügen ein JWKS in jwt-verify ein, um Ihre Richtlinie vorab zu testen.

Fazit

Ein JWT ist ein signierter, kein versiegelter Umschlag: Seine Payload kann jeder lesen, und nur die Signatur zeigt, dass es nicht verändert wurde. Der JWT-Decoder macht die Claims in Sekunden sichtbar, was für das Meiste bei einem 401 oder 403 genügt, und der JWT-Encoder baut ein Token, um einen Fall nachzustellen. Keiner von beiden stellt Vertrauen her. Dafür braucht es die Schlüssel des Ausstellers, einen festgelegten Algorithmus und Prüfungen von aud, iss und exp, wie sie jwt-verify und Ihr eigener Servercode leisten. Halten Sie Test-Secrets aus der Produktion fern, ziehen Sie HMAC-Secrets zufällig und lehnen Sie alg=none ab. Der Hub für Sicherheits-Tools bündelt die Nachbarwerkzeuge für Schlüssel, Zertifikate und Secrets.

Ein Token im Browser prüfen oder bauen

Dekodieren zum Debuggen, verifizieren zum Vertrauen: Eine lesbare Payload beweist nichts

exp, nbf und iat als Sekunden seit 1970 lesen und selbst umrechnen

Den Algorithmus auf dem Server festlegen und alg=none ablehnen

HMAC-Secrets zufällig ziehen, mindestens so lang wie die Hash-Ausgabe

Nie ein aktives Produktions-Token dort einfügen, wo andere es sehen, und jedes Token wie einen Zugangsnachweis behandeln

Teilen Sie diesen Artikel

Teilen Sie diesen Artikel:

JWT erstellen und dekodieren: Token online bauen und prüfen

Ein JWT kann jeder lesen: dekodieren zum Prüfen, signieren zum Testen, verifizieren zum Vertrauen

Kodieren, dekodieren oder verifizieren: Welches Werkzeug beantwortet welche Frage

Einen 401 oder 403 mit einem dekodierten Token debuggen

Vier Fehler, die aus einem Testwerkzeug eine Sicherheitslücke machen

Aufbau eines JWT: drei Base64URL-Segmente und was jedes sagt

Dekodieren und kodieren in den Werkzeugen: die Anleitung

Das kompakte Token einfügen

Header und Payload lesen

Optional die Signatur prüfen

Einen Fehler lesen, falls es einen gibt

Den Algorithmus wählen

Die Claims schreiben

Bei Bedarf einen Ablauf setzen

Den Schlüssel angeben

Das Token kopieren und prüfen

Dieselben Operationen in Ihrem eigenen Code

Einfaches Beispiel

Einfaches Beispiel

Einfaches Beispiel

Fazit

Verwandte Artikel