Entwicklertools · JWT Decoder
Der JWT-Header erklärt: alg, typ, kid und die Felder, denen man nicht vertrauen kann
· Wie es funktioniert
jwt Sicherheit Authentifizierung
Der Header teilt einem Verifizierer mit, wie das Token signiert wurde und welcher Schlüssel verwendet werden soll. In diesem Beitrag wird jedes gemeinsame Header-Feld erläutert, worauf sich ein Verifizierer verlassen kann und welchen Feldern vom Token selbst aus niemals vertraut werden darf.
Das kleine JSON-Objekt, das niemand liest – und die Überprüfungsentscheidungen, die es beeinflusst
Der Header ist so klein, dass er übersehen werden kann, seine Felder sind jedoch häufig am Verifizierungsrouting beteiligt. Das macht es gefährlich, Sichtbarkeit mit Autorität zu verwechseln. ToolAcre dekodiert den Header als JSON-Objekt und zeigt seine Eigenschaften an, aber jedes Byte stammt vom Token-Inhaber und bleibt eine nicht vertrauenswürdige Eingabe.
Ein Verifizierer darf einen Header-Wert nur innerhalb von Einschränkungen verwenden, die aus einer vertrauenswürdigen Konfiguration erstellt wurden. Es sollte nicht zulassen, dass das Token einen akzeptierten Algorithmus, Emittenten oder eine Remote-Schlüsselquelle erfindet. Der Job des Decoders endet bei lesbarem JSON plus Warnungen; Es wird niemals ein Schlüssel ausgewählt oder eine Zulassungs- oder Ablehnungsentscheidung getroffen.
Alg-Anzeige: Der Decoder erklärt nur die in seiner Implementierung genannten Algorithmen
`alg` deklariert den Algorithmus, der laut Token verwendet wurde. ToolAcre enthält Erläuterungen zu HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 und PS512 sowie eine Warnung für `none`. Jede andere Zeichenfolge wird als nicht erkannt angezeigt und nicht als unterstützt behandelt.
Diese Liste ist eine Anzeigefunktion und kein Katalog von Algorithmen, die ToolAcre überprüfen kann: Es überprüft keinen von ihnen. Ein Backend muss seine zulässigen Auswahlmöglichkeiten unabhängig festlegen und eine Nichtübereinstimmung ablehnen. Das Lesen von `alg: RS256` kann nicht beweisen, dass RSA verwendet wurde, ebenso wie das Lesen von `alg: none` ein unsigniertes Token nicht sicher autorisieren kann.
typ und cty – Deklaration des Token-Typs, des at+jwt-Profils für Zugriffstokens und verschachtelter JWTs
`typ` beschreibt den Medientyp oder das Profil, das der Produzent beabsichtigt. ToolAcre warnt, wenn ein Zeichenfolgenwert von `JWT` abweicht; Es erzwingt keine Profilsemantik. Ein `cty`-Feld kann verschachtelten Inhalt beschreiben, aber der aktuelle Decoder verfügt über keinen Verarbeitungspfad für verschachtelte Token und interpretiert dieses Feld nicht.
Die explizite Typisierung kann einem Verifizierer dabei helfen, verschiedene Tokenklassen getrennt zu halten, wenn seine Richtlinie erwartete Werte definiert. Der Scheck gehört weiterhin diesem Prüfer. Ein Token kann sich nicht allein durch die Bekanntgabe einer bevorzugten Bezeichnung zu einem Zugriffstoken machen, und ein Dekodierpanel kann nicht bestimmen, welcher Anwendungsendpunkt es nutzen soll.
kid – die Schlüsselkennung, mit der Prüfer Schlüssel ohne Ausfallzeit wechseln können
`kid` ist eine Schlüsselkennung, kein Schlüsselmaterial und kein Eigentumsnachweis. Ein Dienst, der mehrere vertrauenswürdige Schlüssel rotiert, kann einen authentifizierten Ausstellerkontext und eine eingeschränkte Kennung verwenden, um einen Kandidaten zu finden. Der Bezeichner muss für eine kontrollierte Suche als Eingabe bleiben und nicht für einen Dateipfad, ein Abfragefragment oder eine beliebige URL.
ToolAcre lässt `kid` im Header JSON sichtbar, löst es jedoch nicht auf. Diese Einschränkung ist wichtig: Für eine öffentliche Dekodierungsseite ist kein vertrauenswürdiger Schlüsselspeicher verfügbar. Wenn ein 401 auf die Rotation folgt, vergleichen Sie die angezeigte Kennung mit dem serverseitigen Schlüsselinventar und den Protokollen, ohne davon auszugehen, dass der vorgeschlagene Schlüssel des Tokens legitim ist.
jku, x5u, jwk und x5c – Header-Felder, die auf Schlüssel verweisen, und warum ein Verifizierer sie niemals blind abrufen oder ihnen vertrauen darf
Felder wie `jku` und `x5u` können Standorte benennen, während `jwk` und `x5c` schlüsselbezogene Daten enthalten können. Ihre Anwesenheit macht diese Orte oder Werte nicht vertrauenswürdig. Das Abrufen einer URL oder das Akzeptieren von eingebettetem Material, nur weil ein nicht überprüfter Header bereitgestellt wird, übergibt dem Anforderer eine Sicherheitsentscheidung.
Ein sicherer Verifizierer erhält Schlüssel über eine Emittentenbeziehung und eine Netzwerkrichtlinie, die außerhalb des Tokens festgelegt wird. ToolAcre ruft weder Header-URLs ab noch baut es Vertrauen aus eingebetteten Schlüsseln auf. Wenn während der Überprüfung eines dieser Felder angezeigt wird, ist dies eine Aufforderung zur Überprüfung der Prüferkonfiguration und keine Anweisung, der Kopfzeile zu folgen.
crit – Erweiterungen, die ein Prüfer verstehen oder ablehnen muss
`crit` signalisiert, dass bestimmte Erweiterungen vom Empfänger verstanden werden müssen. Ein Prüfer, der eine solche Erweiterung unterstützt, benötigt einen expliziten Implementierungs- und Ablehnungspfad für unbekannte kritische Namen. Das Ignorieren eines unbekannten kritischen Markers kann dazu führen, dass Hersteller und Verbraucher den geschützten Inhalt unterschiedlich interpretieren.
Die reine Dekodierungsimplementierung verarbeitet `crit` nicht, sodass sie das Roharray anzeigen kann, ohne Kompatibilität zu beanspruchen. Dies ist eine weitere Grenze zwischen Inspektion und Validierung. Wenn ein Produktionstoken auf kritischen Erweiterungen basiert, überprüfen Sie das Verhalten in der tatsächlichen Bibliothek und Konfiguration, anstatt die Unterstützung aus lesbaren JSON abzuleiten.
Ausgearbeitetes Beispiel – Lesen eines realistischen Headers und Entscheiden, welche Felder zur Überprüfung dienen und welche lediglich Informationszwecken dienen
Betrachten Sie `{"alg":"RS256","typ":"JWT","kid":"rotate-7"}`. ToolAcre druckt alle drei Felder hübsch aus und erklärt, dass die RS256-Verifizierung einen öffentlichen Schlüssel des Ausstellers erfordert. Ein Prüfer kann den deklarierten Algorithmus und die Schlüsselkennung notieren und sie dann mit der angehefteten Richtlinie und dem vertrauenswürdigen Schlüsselsatz des Servers vergleichen.
Die Felder dienen der Untersuchung, entscheiden aber nicht unabhängig voneinander. Wenn der Server nur einen anderen Algorithmus zulässt, `rotate-7` nicht im richtigen Ausstellersatz finden kann oder die Signatur ablehnt, überschreibt der lesbare Header dieses Ergebnis nicht. Ebenso darf eine Änderung des Kopftextes ohne Neuberechnung einer gültigen Signatur nicht akzeptiert werden.
Fazit: Der Header ist eine Eingabe, keine Autorität – der ToolAcre JWT-Decoder zeigt den Header an, damit Sie ihn lesen können; Der Prüfer muss selbstständig entscheiden, wem er vertrauen möchte
Behandeln Sie den Header JWT als Eingabe, nicht als Autorität. Seine Werte können dabei helfen, zwischen bereits durch die Konfiguration autorisierten Optionen auszuwählen, ein wahrscheinliches Rotationsproblem zu identifizieren oder eine Profilinkongruenz zu erklären. Sie können kein Vertrauen in ihren eigenen Algorithmus, Schlüssel, URL oder Token-Typ aufbauen.
Verwenden Sie ToolAcre, um einen Testheader zu lesen und verdächtige Werte wie fehlende `alg`, `none` oder ein unerwartetes `typ` anzuzeigen. Gehen Sie dann für jede Folgeentscheidung zum konfigurierten Prüfer. Die Dekodierung beweist nicht die Authentizität, Integrität, Autorisierung oder Identität des Ausstellers, unabhängig davon, wie plausibel der Header aussieht.