Entwicklertools · JWT Decoder
RFC 7519 und die JOSE-Familie: JWT, JWS, JWE, JWK und JWA erklärt
· Hintergrund
jwt Kryptographie Standards
JWT ist ein Mitglied einer Familie von Spezifikationen der IETF JOSE-Arbeitsgruppe. In diesem Beitrag wird erklärt, was jeder RFC definiert, wie sie zusammenpassen und warum ein JWT normalerweise ein JWS ist.
Fünf Akronyme, ein Zeichen – warum in der Dokumentation JWS und JWE erwähnt werden, wenn Sie nur nach JWT gefragt haben Die
Token-Dokumentation bewegt sich zwischen JWT, JWS, JWE, JWK und JWA, da sie verschiedene Schichten desselben Ökosystems beschreiben. Die Verwirrung beginnt, wenn „JWT“ als Abkürzung für jedes kompakte dreiteilige signierte Token verwendet wird. Durch die Trennung von Ansprüchen von der Umschlag- und Schlüsseldarstellung ist die Implementierung leichter nachvollziehbar.
Der Decoder von ToolAcre ist bewusst schmaler als die Familie. Es verarbeitet dreiteilige JWS-förmige Eingaben, deren erste beiden dekodierten Segmente JSON-Objekte sind. Es erkennt eine fünfteilig verschlüsselte kompakte Eingabe und stoppt, da das Lesen von Chiffretext ohne Empfängerschlüssel nicht dasselbe dekodieren würde.
Die JOSE-Dokumente definieren verwandte Formate; Dieses Repository legt keinen Zeitplan für die Arbeitsgruppe fest
Die zugehörigen Spezifikationen stammen aus der Arbeit von IETF JOSE, aber die Repository-Quellen legen nicht den detaillierten organisatorischen Zeitplan fest, der in der Gliederung gefordert wird. Dieser Artikel vermeidet daher das Erfinden von Daten oder Prozesshistorien und konzentriert sich auf die im Tool und Plan beobachtbaren Formatbeziehungen.
Die praktische Frage ist, welcher Schicht die jeweilige Entscheidung obliegt. Anspruchsnamen beschreiben Anwendungsanweisungen, Signaturen schützen codiertes Material, Verschlüsselung schützt Inhalte, JSON-Schlüsselobjekte stellen Schlüsselinformationen dar und Algorithmus-IDs benennen Operationen. Kein Akronym ersetzt das andere.
JWS (RFC 7515) – Signieren beliebiger Inhalte und die von JWTs verwendete kompakte Serialisierung
JWS beschreibt signierte oder MAC-geschützte Inhalte. Seine kompakte Form besteht aus drei Segmenten: geschützter Header, Nutzlast und Signatur. Die Signatureingabe verwendet die ersten beiden codierten Segmente, die durch einen Punkt verbunden sind. Ein JWT bewegt sich üblicherweise in diesem Umschlag, der Form, die ToolAcre teilt und prüft.
Der Header und die Nutzlast können in JSON dekodiert werden, während die Signatur aus Bytes und nicht aus einem dritten Objekt besteht. ToolAcre meldet das Vorhandensein und die Größe der Signatur, markiert sie jedoch immer als nicht überprüft. Somit kann es die JWS-Struktur veranschaulichen, ohne Anspruch auf ein kryptografisches Ergebnis zu erheben.
JWE (RFC 7516) – Verschlüsselung von Inhalten mit einer fünfteiligen Serialisierung
JWE beschreibt verschlüsselte Inhalte. Seine kompakte Form besteht aus fünf Segmenten, die einen geschützten Header, verschlüsseltes Schlüsselmaterial, Initialisierungswert, Chiffretext und Authentifizierungs-Tag darstellen. Vier Punkte sind daher ein starker struktureller Hinweis darauf, dass ein dreiteiliger JWT-Decoder eine andere Hülle erhalten hat.
ToolAcre gibt einen bestimmten JWE-Fehler aus und erklärt, dass Inhalte ohne den Entschlüsselungsschlüssel nicht gelesen werden können. Chiffretext wird nicht als fehlerhaft JSON behandelt und es wird auch nicht versucht, zufällige Bytes anzuzeigen. Verschlüsselung und Signierung können ebenfalls kombiniert werden, eine verschachtelte Verarbeitung liegt jedoch außerhalb dieser Route.
JWK und JWA (RFC 7517 und 7518) – Darstellung von Schlüsseln als JSON und Benennung der Algorithmen
JWK stellt eine JSON-Darstellung für kryptografische Schlüsselinformationen bereit, während JWA Algorithmus-IDs und zugehörige Parameter benennt, die in JOSE verwendet werden. Ihre Existenz bedeutet nicht, dass ein Token seinen eigenen vertrauenswürdigen Schlüssel oder Algorithmus wählen kann. Ein Verifizierer muss sowohl die Aussteller- als auch die Anwendungsrichtlinie einschränken.
Die Anmerkungen zum ToolAcre-Algorithmus erläutern nur eine endliche Menge an Beschriftungen, die in der Quelle vorhanden sind, und nennen alles andere unerkannt. Es handelt sich um Beschreibungen, nicht um Implementierungen. Der Decoder importiert weder ein JWK noch führt er einen Algorithmus aus JWA aus, wodurch die Inspektionsgrenze explizit bleibt.
JWT (RFC 7519) – das Anspruchsformat, das auf JWS oder JWE läuft
JWT definiert ein Anspruchsobjekt und registrierte Namen wie Aussteller, Betreff, Zielgruppe und NumericDates. Diese Ansprüche können in einer signierten oder verschlüsselten JOSE-Struktur übertragen werden. Die Nutzlastschicht antwortet daher, „welche Aussagen dargestellt werden“, während der Umschlag antwortet, wie diese Bytes geschützt oder verborgen werden.
ToolAcre erwartet, dass es sich bei der dekodierten Nutzlast um ein JSON-Objekt handelt, und listet seine Ansprüche auf. Ein Array, eine Zahl oder Null wird für dieses Tool abgelehnt. Sogar ein wohlgeformtes Objekt bleibt nicht vertrauenswürdig, bis der entsprechende Umschlag von einem konfigurierten Verifizierer oder Empfänger verarbeitet wird.
Was dies nicht abdeckt – die späteren Profile wie RFC 8725 Best Practices und RFC 9068 Zugriffstokens, die ihre eigenen Beiträge haben
Spätere Best-Practice- und Profildokumente können die Verwendung dieser allgemeinen Mechanismen einschränken. Sie verdienen eine gesonderte Behandlung, da ein Basisformat keine anwendungsspezifischen Emittenten-, Zielgruppen- oder Tokentyp-Richtlinien bereitstellt. Dieser Artikel behauptet nicht, dass der Decoder ein solches Profil implementiert.
Notieren Sie bei der Überprüfung eines Systems das genaue Profil, den erwarteten Umschlag, die akzeptierten Algorithmen, die Schlüsselquelle und die Anspruchsregeln. Diese Liste verhindert, dass die Vertrautheit mit Akronymen zu einer Annahme von Kompatibilität oder Sicherheit wird.
Takeaway: JWT sind die Ansprüche, JWS ist der Umschlag – der ToolAcre JWT-Decoder liest die JWS-Kompaktform und zeigt den JWT-Header und die darin enthaltenen Ansprüche an
JWT benennt die Anspruchsschicht; JWS und JWE stellen Schutzumschläge zur Verfügung; JWK stellt Schlüsseldaten dar; JWA benennt Auswahlmöglichkeiten für Algorithmen. ToolAcre liest die übliche dreiteilige signierte Form und zeigt Header und Ansprüche an, verweigert jedoch die Überprüfung oder Entschlüsselung.
Verwenden Sie diese Karte, um die richtige nächste Frage zu stellen. Lesbar JSON identifiziert die Anspruchsschicht. Drei oder fünf Segmente identifizieren wahrscheinliche Hüllkurvenfamilien. Vertrauen hängt immer noch von unabhängig konfigurierter Kryptografie und Richtlinie ab und nicht davon, dass der Decoder ein Akronym erkennt.