Entwicklertools · JWT-Decoder
Anatomie eines JWT: Aufteilung in Punkte und Dekodierung von Base64url
· Wie es funktioniert
jwt Kodierung Sicherheit
Ein JWT besteht aus drei durch Punkte getrennten Base64-URL-Segmenten. Dieser Beitrag dekodiert jeden Teil von Hand, erklärt, warum das Signatursegment kein Text ist, und zeigt, was ein Decoder Ihnen sagen kann und was nicht.
Die lange Zeichenfolge im Authorization-Header – was Sie sehen und warum sie genau zwei Punkte enthält
Ein Inhabertoken kommt oft als kompakte, durch Punkte getrennte Zeichenfolge in einem Autorisierungsheader an. Ein typisches signiertes JWT in kompakter JWS-Form hat drei Segmente und daher zwei Trennpunkte. Ein aktives Token ist ein Berechtigungsnachweis: Fügen Sie keine Produktionstoken in eine Demonstration ein.
Kompakte Serialisierung – Header, Payload und Signatur als drei base64url-Segmente
Bei der kompakten JWS-Serialisierung ist das erste Segment der geschützte Header, das zweite die Nutzlast und das dritte eine Signatur oder MAC. Die Signatur umfasst die codierten ersten beiden Segmente, verbunden durch einen Punkt. Durch Teilen der Zeichenfolge werden die Segmente lokalisiert. es kann kein Vertrauen aufbauen.
Base64url ohne Auffüllung – das von JWS verwendete Alphabet und warum die Segmente keine abschließenden Gleichheitszeichen haben
Base64url verwendet - und _ anstelle von + und / im normalen Base64. Compact JWS lässt Trailing = Padding weg; Ein Decoder kann die Auffüllung vor der Decodierung wiederherstellen. Beim Dekodieren entstehen Bytes. Dekodieren Sie für JSON-Header und -Ansprüche die Bytes als UTF-8, bevor Sie den Text analysieren.
Der Header – ein kleines JSON-Objekt, das den Algorithmus und häufig auch den Schlüssel benennt
Der Header ist normalerweise JSON und enthält alg und manchmal eine Schlüsselkennung, kid. Dies sind Behauptungen, die vom Token selbst gemacht werden. Ein Verifizierer muss seine eigene Richtlinie für zulässige Algorithmen durchsetzen und den entsprechenden Schlüssel sicher erhalten; Das Lesen von Alg allein ist keine Autorisierung.
Die Nutzlast – ein JSON-Objekt von Ansprüchen, lesbar für jeden, der das Token besitzt
Die Nutzlast enthält Ansprüche wie sub, exp und aud. Jeder, der den Token besitzt, kann ihn lesen; Verschlüsselung ist keine Verschlüsselung. Ein exp NumericDate zählt Sekunden seit der Unix-Epoche, aber eine unbestätigte Behauptung hat keine Autorität. Speichern Sie Geheimnisse nicht in einer lesbaren Nutzlast.
Die Signatur – Rohbytes über die ersten beiden Segmente, bedeutungslos als Text und nutzlos ohne Schlüssel
Das letzte Segment besteht aus in base64url codierten Signaturbytes, nicht aus einem dritten JSON-Objekt. Für die Validierung sind ein kryptografischer Algorithmus, ein Schlüssel und eine Anwendungsrichtlinie erforderlich. ToolAcre führt bewusst keine Verifizierung durch: Es meldet das Vorhandensein einer Signatur und markiert „signaturVerified“ immer als „falsch“.
Ausgearbeitetes Beispiel: Segmentweise Dekodierung eines Beispiel-Tokens, einschließlich des angezeigten JSON
Nehmen Sie den nicht sensiblen Demonstrationsheader {"alg": "HS256", "typ": "JWT"} und die Nutzlast {"sub": "demo"}. Ihre Base64URL-Kodierungen sind eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 und eyJzdWIiOiJkZW1vIn0. Durch die Dekodierung wird der JSON wiederhergestellt. Durch das Anhängen eines beliebigen dritten Segments wird das Token nicht authentisch.
Fazit: Bei der Dekodierung handelt es sich um Lesen, nicht um Vertrauen – der JWT-Decoder von ToolAcre zeigt den Header und die Nutzlast an und überprüft niemals die Signatur, daher beweist nichts, was er anzeigt, die Echtheit des Tokens
Beim Dekodieren handelt es sich um Lesen, nicht um Vertrauen. Verwenden Sie den ToolAcre JWT-Decoder für den Header, die Ansprüche und die Warnungen eines Wegwerf-Tokens. Verwenden Sie den vertrauenswürdigen Prüfer Ihrer Anwendung, um zu entscheiden, ob ein signiertes Token gültig ist. Angezeigte Ansprüche allein dürfen niemals den Zugriff gewähren.