Ist es sicher, mein JWT hier einzufügen?

Ja. Die Dekodierung erfolgt vollständig in Ihrem Browser – das Token wird niemals an einen Server gesendet. Bei JWTs handelt es sich jedoch um Anmeldeinformationen – geben Sie sie nicht öffentlich weiter (in Screenshots, Stack Overflow-Beiträgen usw.), da sie möglicherweise Zugriff auf Ihre Konten gewähren.

Verifiziert dieses Tool die JWT-Signatur?

Dieses Tool dekodiert den Token-Inhalt und zeigt ihn an. Für die Signaturüberprüfung ist der geheime Schlüssel (HMAC) oder der öffentliche Schlüssel (RSA/ECDSA) erforderlich, der auf Ihrem Server verbleiben sollte. Das Tool zeigt den verwendeten Algorithmus an, kann ihn aber ohne den Schlüssel nicht verifizieren.

Was bedeuten die Standard-JWT-Ansprüche?

iss = Aussteller, sub = Betreff (Benutzer-ID), exp = Ablaufzeit (Unix-Zeitstempel), iat = ausgestellt um, nbf = nicht vorher, aud = Zielgruppe, jti = JWT-ID. Benutzerdefinierte Ansprüche können beliebige anwendungsspezifische Daten enthalten.

Warum kann jemand ein JWT entschlüsseln?

JWTs sind codiert, nicht verschlüsselt. Die Nutzdaten sind Base64URL-codiert (nicht verschlüsselt), sodass sie von jedem gelesen werden können. Die Signatur verhindert Manipulationen, nicht das Lesen. Speichern Sie niemals vertrauliche Daten (Passwörter, SSNs) in JWT-Nutzdaten.

Warum fehlt einigen Token eine Signatur?

Token mit alg: none haben keine Signatur. Sie sind laut Spezifikation gültige JWTs, bieten jedoch keine Authentizitätsgarantien und sollten nicht in der Produktion akzeptiert werden.

Sind JWTs verschlüsselt?

Standard-JWT-Nutzlasten sind signiert, aber nicht verschlüsselt. JWE (JSON Web Encryption, RFC 7516) ist ein separates Format für verschlüsselte Token. Die meisten JWTs in freier Wildbahn sind JWS (nur signiert).

Wird mein Token auf einen Server hochgeladen?

Nein. Die Dekodierung erfolgt in Ihrem Browser. Der Token verlässt Ihr Gerät nicht.

Wie lang sind JWTs normalerweise?

Irgendwo zwischen einigen Hundert und mehreren Tausend Zeichen. Die Länge hängt von der Anzahl und Größe der Ansprüche sowie der Signaturlänge ab (die vom Algorithmus abhängt).

JWT-Token Decoder | Any-Tools.net

Über dieses Tool

JSON Web Tokens (JWT) sind ein kompaktes, URL-sicheres Format zur Übertragung von Ansprüchen zwischen zwei Parteien, definiert durch RFC 7519. Ein JWT besteht aus drei durch Punkte getrennten Base64-URL-codierten Segmenten: Header (Algorithmus und Token-Typ), Payload (Ansprüche) und Signatur (kryptografischer Authentizitätsnachweis). Der Header und die Nutzlast sind aus Gründen der URL-Sicherheit JSON und base64url-codiert. Die Signatur verwendet einen von mehreren Algorithmen (HS256, RS256, ES256 und andere) über den codierten Header und die Nutzlast.

Für die Dekodierung eines JWT – die Aufteilung in Segmente und deren Base64-Dekodierung – ist kein Geheimnis erforderlich. Jeder, der über den Token-Text verfügt, kann dessen Header und Payload lesen. Die Signatur kann jedoch nur mit dem geheimen (HMAC) oder öffentlichen Schlüssel (asymmetrisch) verifiziert werden. Die Dekodierung dient der Kontrolle; Durch die Verifizierung wird die Authentizität nachgewiesen.

Dieser Decoder teilt das Token auf, dekodiert jedes Segment base64, analysiert den Header und die Nutzlast als JSON und zeigt das Ergebnis an. Es wird nicht versucht, die Signatur zu überprüfen, da hierfür der geheime oder öffentliche Schlüssel erforderlich ist, über den der Decoder nicht verfügt. Bei der dekodierten Ausgabe handelt es sich um eine schreibgeschützte Inspektion – nützlich zum Debuggen von Tokens, aber kein Ersatz für eine ordnungsgemäße Überprüfung im Anwendungscode.

Warum JWTs dekodieren?

Das Debuggen von Authentifizierungsproblemen erfordert fast immer die Überprüfung von Token. Ein Token, das im Code gültig aussieht, weist möglicherweise falsche Ansprüche, einen unerwarteten Algorithmus, einen abgelaufenen Exp-Zeitstempel oder eine Nichtübereinstimmung mit der Zielgruppe auf. Die Entschlüsselung des Tokens zeigt genau, was der Emittent produziert hat.

Auch die Überprüfung der Token während der Integrationsarbeit hilft. Wenn Sie eine Verbindung zu einer API oder einem Identitätsanbieter eines Drittanbieters herstellen, lassen sich die tatsächlichen Anspruchsnamen, -formate und -strukturen am besten durch die Dekodierung von Beispieltokens verstehen, anstatt sich auf möglicherweise veraltete Dokumentation zu verlassen.

So verwenden Sie es

Fügen Sie das Token ein und erhalten Sie den analysierten Inhalt.

Fügen Sie Ihr JWT ein: Legen Sie das vollständige Token (header.payload.signature) im Eingabebereich ab. Der Decoder akzeptiert Token mit oder ohne das optionale Bearer-Präfix.
Überprüfen Sie den Header: Der Header zeigt den Signaturalgorithmus (alg) und den Tokentyp (typ). Gängige Algorithmen sind HS256, RS256 und ES256. Achten Sie auf alg: none, das ein nicht signiertes Token signalisiert und in der Produktion selten sicher ist.
Untersuchen Sie die Nutzlast: Die Nutzlast enthält die Ansprüche: iss (Aussteller), sub (Betreff), aud (Zielgruppe), exp (Ablauf), iat (ausgestellt bei) und alle anwendungsspezifischen Ansprüche. Standardzeitstempel sind Unix-Epochensekunden.
Separat überprüfen: Der Decoder überprüft die Signatur nicht. Um die Authentizität zu überprüfen, führen Sie das Token über eine JWT-Bibliothek mit dem entsprechenden geheimen oder öffentlichen Schlüssel in Ihrem Anwendungscode aus.

Häufige Anwendungsfälle

Debuggen von Fehlern bei abgelaufenen Token — Durch die Dekodierung des Tokens wird der Exp-Anspruch sichtbar. Vergleichen Sie mit der aktuellen Zeit, um zu bestätigen, ob der Ablauf die tatsächliche Ursache ist.
Verständnis der Anspruchsstruktur eines Drittanbieter-Tokens — Identitätsanbieter (Auth0, Okta, Cognito) stellen Token mit anbieterspezifischen Anspruchslayouts aus. Die Dekodierung von Beispiel-Tokens zeigt die tatsächliche Struktur.
Überprüfung von Token während der Integration — Bei der Integration von SSO- oder OAuth-Flows hilft die Dekodierung von Tokens bei jedem Schritt dabei, zu überprüfen, ob die Daten wie erwartet formatiert sind.
Überprüfung des Token-Inhalts auf sensible Daten — Token sind standardmäßig nicht verschlüsselt; Die Nutzlast ist lesbar. Durch die Dekodierung vorhandener Token kann sichergestellt werden, dass vertrauliche Daten nicht versehentlich einbezogen werden.
Überprüfung der Zielgruppen- und Emittentenansprüche — Um sich gegen Token-Verwirrung zu verteidigen, ist eine korrekte Aud- und Iss-Behandlung erforderlich. Durch die Dekodierung der Token während des Tests wird bestätigt, dass diese Ansprüche korrekt ausgefüllt sind.

Technische Details

Das JWT-Format besteht aus drei Segmenten, die durch Punkte verbunden sind. Jedes Segment ist base64-URL-codiert – die URL-sichere Variante von base64, die - und _ anstelle von + und / verwendet, wobei Auffüllungen manchmal weggelassen werden. Die Dekodierung erfordert das Rückgängigmachen der URL-sicheren Ersetzungen, das Auffüllen des Segments und die Base64-Dekodierung.

Der Header und die Nutzlast sind nach der Dekodierung JSON. Das Signatursegment ist binär (Rohsignaturbytes) und nicht für Menschen lesbar. Es erfordert, dass der Bestätigungsschlüssel nützlich ist.

Allgemeine Ansprüche, die in RFC 7519 definiert sind: iss (Aussteller), sub (Subjekt-ID), aud (Zielgruppe), exp (Ablauf als Unix-Epochensekunden), nbf (nicht-vorheriger Zeitstempel), iat (ausgestellt am Zeitstempel), jti (eindeutige Token-ID). Anwendungsspezifische Ansprüche können mit einem beliebigen Namen angezeigt werden.

Best Practices

Vertrauen Sie niemals einem nicht verifizierten JWT — Durch die Dekodierung wird lediglich der Inhalt preisgegeben; es beweist nicht die Echtheit. Überprüfen Sie die Signatur immer mit dem richtigen Schlüssel im Anwendungscode, bevor Sie den Ansprüchen vertrauen.
Achten Sie auf Alg: keine — Token mit alg: none haben keine Signatur. Anwendungscode, der sie akzeptiert, ist fälschungsgefährdet. Erfordern Sie in Ihrer Verifizierungskonfiguration immer einen bestimmten Algorithmus.
Seien Sie vorsichtig mit sensiblen Daten in Nutzlasten — JWT-Nutzlasten sind für jeden mit dem Token lesbar. Verschlüsseln Sie die Nutzlast (verwenden Sie JWE), wenn sie Daten enthält, die geheim sein müssen.
Validieren Sie exp vor der Verarbeitung — Ein abgelaufenes Token sollte abgelehnt werden, auch wenn die Signatur gültig ist. JWT-Bibliotheken prüfen exp normalerweise automatisch; Überprüfen Sie, ob Ihre Bibliothek dies tut.

Häufig gestellte Fragen

Ist es sicher, mein JWT hier einzufügen?: Ja. Die Dekodierung erfolgt vollständig in Ihrem Browser – das Token wird niemals an einen Server gesendet. Bei JWTs handelt es sich jedoch um Anmeldeinformationen – geben Sie sie nicht öffentlich weiter (in Screenshots, Stack Overflow-Beiträgen usw.), da sie möglicherweise Zugriff auf Ihre Konten gewähren.
Verifiziert dieses Tool die JWT-Signatur?: Dieses Tool dekodiert den Token-Inhalt und zeigt ihn an. Für die Signaturüberprüfung ist der geheime Schlüssel (HMAC) oder der öffentliche Schlüssel (RSA/ECDSA) erforderlich, der auf Ihrem Server verbleiben sollte. Das Tool zeigt den verwendeten Algorithmus an, kann ihn aber ohne den Schlüssel nicht verifizieren.
Was bedeuten die Standard-JWT-Ansprüche?: iss = Aussteller, sub = Betreff (Benutzer-ID), exp = Ablaufzeit (Unix-Zeitstempel), iat = ausgestellt um, nbf = nicht vorher, aud = Zielgruppe, jti = JWT-ID. Benutzerdefinierte Ansprüche können beliebige anwendungsspezifische Daten enthalten.
Warum kann jemand ein JWT entschlüsseln?: JWTs sind codiert, nicht verschlüsselt. Die Nutzdaten sind Base64URL-codiert (nicht verschlüsselt), sodass sie von jedem gelesen werden können. Die Signatur verhindert Manipulationen, nicht das Lesen. Speichern Sie niemals vertrauliche Daten (Passwörter, SSNs) in JWT-Nutzdaten.
Warum fehlt einigen Token eine Signatur?: Token mit alg: none haben keine Signatur. Sie sind laut Spezifikation gültige JWTs, bieten jedoch keine Authentizitätsgarantien und sollten nicht in der Produktion akzeptiert werden.
Sind JWTs verschlüsselt?: Standard-JWT-Nutzlasten sind signiert, aber nicht verschlüsselt. JWE (JSON Web Encryption, RFC 7516) ist ein separates Format für verschlüsselte Token. Die meisten JWTs in freier Wildbahn sind JWS (nur signiert).
Wird mein Token auf einen Server hochgeladen?: Nein. Die Dekodierung erfolgt in Ihrem Browser. Der Token verlässt Ihr Gerät nicht.
Wie lang sind JWTs normalerweise?: Irgendwo zwischen einigen Hundert und mehreren Tausend Zeichen. Die Länge hängt von der Anzahl und Größe der Ansprüche sowie der Signaturlänge ab (die vom Algorithmus abhängt).

JWT-Token Decoder

Ähnliche Tools

URL-Encoder / Decoder

Base64-Encoder / Decoder

JSON-Formatierer & Validator

XML-Formatierer & Validator

Über dieses Tool

Warum JWTs dekodieren?

So verwenden Sie es

Häufige Anwendungsfälle

Technische Details

Best Practices

Häufig gestellte Fragen

Related Articles

Essential Developer Tools: JSON, Base64, RegEx, and More

Hashing, Encryption, and Encoding Explained: A Developer's Security Guide

Spreadsheet & Data Conversion Guide: Excel, CSV, JSON, and More

Why Browser-Based Tools Are the Future: No Installs, No Uploads, No Risk