Entwicklertools · JWT Decoder
Base64 vs. Base64url: Warum ein JWT in einem Standard-Base64-Decoder fehlschlägt
· Wie es funktioniert
jwt base64 Kodierung
Fügen Sie ein JWT-Segment in einen gewöhnlichen Base64-Decoder ein und es kann zu Problemen mit Zeichen oder Auffüllungen kommen. In diesem Beitrag werden die JWS-Mandate der Base64URL-Variante und die Konvertierung zwischen beiden erläutert.
Ungültiges Zeichen, falsche Auffüllung – die Fehler, die auftreten, wenn base64 auf base64url trifft
Eine Meldung über „ungültiges Zeichen“ oder „falsche Auffüllung“ bedeutet oft, dass ein JWT-Segment an einen Decoder übergeben wurde, der normales Base64 erwartet. Der Token kann korrekt kopiert werden. Seine Darstellung folgt den Base64URL-Konventionen, während das empfangende Dienstprogramm ein verwandtes, aber nicht identisches Alphabet akzeptiert oder auf explizitem Auffüllen besteht.
ToolAcre vermeidet diese Diskrepanz zwischen Header und Payload. Sein Byte-Decoder entfernt Leerzeichen, übersetzt URL-sichere Symbole, stellt ausgelassene Auffüllungen wieder her, wenn die Länge dies zulässt, und konvertiert dann Bytes als strikt UTF-8. Ein Fehler in jeder Phase wird zu einem INVALID_JWT-Fehler und nicht zu einer reinen Browserausnahme.
Zwei Alphabete – Plus und Schrägstrich im Vergleich zu Bindestrich und Unterstrich und warum URLs die Änderung erzwangen
Standard Base64 verwendet Plus und Schrägstrich für die letzten beiden Alphabetpositionen. Base64url weist denselben Positionen Bindestrich und Unterstrich zu. Die zugrunde liegenden Sechs-Bit-Werte ändern sich nicht, daher bleibt bei der Übersetzung von `-` in `+` und `_` in `/` jedes decodierte Byte erhalten; lediglich die transportsichere Schreibweise ändert sich.
Diese Ersetzungen sind in Kanälen wichtig, in denen Plus oder Schrägstrich bereits eine Syntax haben. Eine URL-sichere Schreibweise reduziert versehentliche Interpretationen durch Formular- oder Pfadverarbeitung. Es fügt keine Geheimhaltung, Integrität oder Authentizität hinzu. Jeder, der ein Segment empfängt, kann die Ersetzungen umkehren und dieselben Bytes ohne kryptografischen Schlüssel wiederherstellen.
Padding – warum JWS die Gleichheitszeichen entfernt und wie man sie für einen strikten Decoder wiederherstellt
ToolAcre akzeptiert weggelassene Auffüllungen. Nach der Alphabetnormalisierung wird die Segmentlänge modulo vier untersucht. Für den Rest von zwei sind zwei Gleichheitszeichen erforderlich, für den Rest von drei ist ein Gleichheitszeichen erforderlich. Ein Rest von eins ist für einen vollständigen Base64-Wert unmöglich und wird als abgeschnittene Zeichenfolge abgelehnt und nicht in die richtige Form gebracht.
Bei der Wiederherstellung der Polsterung handelt es sich um eine mechanische Rahmung, nicht um eine Token-Reparatur. Durch das Hinzufügen von Gleichheitszeichen können beim Kopieren verlorene Zeichen nicht wiederhergestellt werden, und eine erfolgreiche Bytedekodierung zeigt nicht, dass die Bytes von einem Aussteller stammen. Die Implementierung rekonstruiert lediglich die kanonische Länge, die der Browser-Decoder vor dem Aufruf von `atob` benötigt.
Den gesamten Token auf einmal entschlüsseln – der Fehler, nicht zuerst in die Punkte aufzuteilen
Ein kompaktes signiertes Token muss in seine Punkte aufgeteilt werden, bevor ein Segment dekodiert wird. Durch die Übergabe von `header.payload.signature` an eine Base64-Funktion werden Punkte eingeführt, die zur Serialisierung JWT gehören, nicht zu einem der Base64-Alphabete. ToolAcre erfordert genau drei Segmente für diese JWS-förmige Eingabe und meldet die beobachtete Anzahl, wenn diese Struktur fehlt.
Der fünfteilige Fall erhält eine separate JWE-Nachricht, da es sich bei der verschlüsselten kompakten Serialisierung nicht um dasselbe Objekt handelt. Zwei oder vier Teile deuten stattdessen auf eine Kürzung oder eine falsche Eingabe hin. Diese Strukturprüfung erfolgt vor der Interpretation von JSON, wodurch ein Kopierfehler von fehlerhaftem codiertem Text oder fehlerhaftem JSON unterschieden wird.
Funktioniertes Beispiel – Konvertieren eines Segments von base64url in base64, Auffüllen und Dekodieren in JSON
Für eine funktionierende Konvertierung nehmen Sie `eyJhbGciOiJIUzI1NiJ9`. Es enthält keine alphabetischen Zeichen, die sich zwischen den Varianten unterscheiden, aber die fehlende Auffüllung verdeutlicht dennoch die Pipeline. Seine Länge ermöglicht die Wiederherstellung der Polsterung; Die Dekodierung ergibt UTF-8 Bytes für `{"alg":"HS256"}`, und das Parsen von JSON erzeugt ein Objekt mit einer `alg`-Eigenschaft.
Ein Segment, das einen Bindestrich oder einen Unterstrich enthält, folgt der gleichen Reihenfolge, wobei die beiden Symbolersetzungen zuerst erfolgen. ToolAcre führt diese Vorgänge innerhalb von `base64ToBytes` aus, dann analysiert `decodeSegment` den resultierenden Text. Der angezeigte Algorithmus ist das, was auch immer der nicht verifizierte Header deklariert; Es ist nicht als Verifizierungsrichtlinie ausgewählt.
Unicode in Ansprüchen – warum die dekodierten Bytes als UTF-8 gelesen werden müssen, um Namen korrekt anzuzeigen
Ansprüche können Akzente, CJK-Zeichen oder Emojis enthalten. Base64 arbeitet mit Bytes, sodass die Behandlung jedes dekodierten Bytes als unabhängiges Zeichen dazu führt, dass Multibyte-Text beschädigt wird. Der richtige Pfad besteht aus codierten Symbolen in Bytes und dann einem UTF-8-Decoder. ToolAcre erstellt `TextDecoder` im fatalen Modus, sodass ungültiges UTF-8 lautstark fehlschlägt.
Die Tests decken eine Nutzlast ab, die `Zoë 世界 🙂` enthält, und erwarten nach der Dekodierung die genaue Zeichenfolge. Dieses Ergebnis beweist, dass die Byte-zu-Text-Pipeline diesen Testwert beibehalten hat. Es sagt weiterhin nichts darüber aus, ob die in der Payload genannte Person existiert, ob der Emittent den Anspruch genehmigt hat oder ob der Token verändert wurde.
Was dies nicht abdeckt – das Signatursegment, das in Bytes statt in Text dekodiert und einen Schlüssel benötigt, um etwas zu bedeuten
Das Signatursegment liegt außerhalb des Pfads JSON. ToolAcre behält seine ursprüngliche kodierte Form und versucht nur, die dekodierte Bytelänge zu messen. Ungültige Base64-Signatur erzeugt eine Warnung, verhindert aber nicht die Header- und Payload-Inspektion; Ein leeres drittes Segment erzeugt eine andere Warnung, dass keine Signaturbytes vorhanden sind.
Keines der Ergebnisse ist ein Verifizierungsergebnis. Eine aussagekräftige Signaturvalidierung erfordert vertrauenswürdiges Schlüsselmaterial, einen zugelassenen Algorithmus, der unabhängig von vom Angreifer kontrollierten Eingaben ausgewählt wird, und Anwendungsprüfungen. Eine Byteanzahl ist bei der Formdiagnose nützlich, aber null oder zweiunddreißig gemessene Bytes können keine Anfrage autorisieren oder einen Aussteller festlegen.
Takeaway: Verwenden Sie einen Decoder, der base64url spricht – der ToolAcre JWT-Decoder verwaltet das Alphabet und die Auffüllung für den Header und die Nutzlast
Verwenden Sie einen Decoder, der base64url versteht, wenn der unmittelbare Job JSON überprüft. ToolAcre verarbeitet das Alphabet, weggelassene Auffüllungen, den strengen UTF-8 und den reinen Objekt-JSON für die ersten beiden Segmente. Außerdem werden unmögliche Längen abgelehnt und Analysefehler in Nachrichten eingeschlossen, die angeben, ob der Header oder die Nutzlast fehlgeschlagen ist.
Halten Sie an dieser Grenze an. Eine saubere Dekodierung bedeutet, dass die Zeichenfolge wiederherstellbare Bytes und geeignete JSON-Objekte hatte. Dies bedeutet nicht, dass seine Ansprüche vertrauenswürdig, authentifiziert, autorisiert oder unverändert sind. Nur ein separat konfigurierter Verifizierer kann diese Fragen beantworten, und dieses Browser-Tool stellt bewusst keinen Verifizierungsvorgang zur Verfügung.