Entwicklertools · JWT Decoder
Debuggen eines 401: Was in einem entschlüsselten JWT überprüft werden muss, bevor die API dafür verantwortlich gemacht wird
· Warum es wichtig ist
jwt Debugging Authentifizierung
Die meisten Token-Ablehnungen sind auf eine Handvoll Anspruchsprobleme zurückzuführen, die Sie durch Lesen der Nutzdaten erkennen können. Dieser Beitrag enthält eine Checkliste, von Ablauf- über Zielgruppen- bis hin zu Copy-Paste-Fehlern, um diese zu überprüfen.
Es hat gestern funktioniert – der 401, der ohne Codeänderung angezeigt wird
Ein 401, der ohne eine Änderung des Client-Codes angezeigt wird, kann auf das Alter des Tokens, die Richtlinien des Ausstellers, die Schlüsselrotation, die Zielgruppenauswahl oder eine beschädigte Kopie zurückzuführen sein. Beginnen Sie mit Beweisen, anstatt davon auszugehen, dass die API ausgefallen ist. Bewahren Sie die Antwortdetails und Korrelationskennungen auf, bevor Sie die Anmeldeinformationen manipulieren.
Dekodieren Sie nur eine abgelaufene, synthetische oder entsprechend kontrollierte Kopie. ToolAcre kann Struktur- und Anspruchshinweise offenlegen, aber es kann nicht jede Server-Ablehnung identifizieren, da es keinen Schlüssel, keine Ausstellerrichtlinie oder keine API-Protokolle hat. Die Checkliste grenzt die Fragen ein; es ersetzt nicht das Urteil des Ressourcenservers.
Fehler zuerst kopieren – „Bearer“-Präfixe, nachgestellte Zeilenumbrüche und abgeschnittene Token
Überprüfen Sie zuerst den kopierten Wert. ToolAcre schneidet umgebende Leerzeichen ab und entfernt das Präfix `Bearer `, bei dem die Groß-/Kleinschreibung nicht beachtet wird und das das häufige Einfügen von Autorisierungsheadern übernimmt. Es sind dann genau drei durch Punkte getrennte Segmente erforderlich. Eine falsche Zählung weist auf eine Kürzung, die falsche Token-Form oder zusätzliche Satzzeichen hin, bevor mit der Anspruchsanalyse begonnen wird.
Ein leerer Header oder eine leere Nutzlast schlägt speziell fehl. Ungültige base64url, ungültige UTF-8 und ungültige JSON weisen separate Fehler auf. Diese Unterscheidungen helfen bei der Feststellung, ob der Token durch den Transport beschädigt wurde. Die Signatur kann fehlerhaft sein, ohne dass die Prüfung blockiert wird, aber diese Warnung bleibt ein wahrscheinlicher Verifizierungsfehler, der eine serverseitige Bestätigung erfordert.
exp und nbf: Überprüfen Sie sekundenbasierte Werte, ohne die Anzeige in ein Gültigkeitsurteil umzuwandeln
Überprüfen Sie als Nächstes die numerischen Werte `exp` und `nbf`. ToolAcre multipliziert Sekunden mit 1,000, zeigt UTC an und beschriftet einen früheren Ablauf oder ein zukünftiges Nicht-vorher-Ablaufdatum relativ zur Browseruhr. Ein dreizehnstelliger Wert kann darauf hinweisen, dass Millisekunden dort geschrieben wurden, wo Sekunden erwartet wurden.
Fördern Sie diese Etiketten nicht zur Durchsetzung. Ein gefälschter Token kann einen zukünftigen Ablauf beanspruchen und der Server verwendet möglicherweise eine andere Takt- oder Spielraumrichtlinie. Die Anzeige identifiziert arithmetisch sinnvolle Vergleiche mit vertrauenswürdigen Protokollen; Die kryptografische Überprüfung muss erfolgreich sein, bevor die Ansprüche die Akzeptanz beeinflussen können.
aud und iss – stammt dieses Token für diese API von dem Aussteller, dem diese API vertraut?
`aud` sollte den beabsichtigten Empfänger gemäß der API-Richtlinie identifizieren, während `iss` mit der vertrauenswürdigen Emittentenbeziehung übereinstimmen sollte. ToolAcre listet beide als dekodierte Werte auf und erläutert ihre registrierte Bedeutung. Es vergleicht sie nicht mit einer API-Konfiguration und bindet keine Ausstellerzeichenfolge an einen Schlüsselsatz.
Eine plausible Emittenten-URL und ein plausibler Zielgruppenname können erfunden werden. Vergleichen Sie die genauen dekodierten Werte erst mit den konfigurierten Erwartungen des Servers, nachdem Sie die Signaturüberprüfungsgrenze beibehalten haben. Wenn sich mehrere Dienste die Identitätsinfrastruktur teilen, sind Zielgruppenprüfungen besonders wichtig, um zu verhindern, dass ein gültiger Token für einen Dienst bei einem anderen verwendet wird.
Der Tokentyp wird möglicherweise durch Header und Ansprüche vorgeschlagen, die Dekodierung kann diese Klassifizierung jedoch nicht authentifizieren
Ein ID-Token und ein Zugriffstoken können beide wie dreiteilige JWTs aussehen. Überschrift `typ`, Zielgruppe, Bereiche und profilspezifische Ansprüche können darauf hinweisen, welchen Anspruch Sie haben. ToolAcre warnt vor einer unerwarteten Zeichenfolge `typ`, implementiert jedoch keine OpenID Connect- oder OAuth-Token-Klassifizierung.
Verwenden Sie die Ausstellerdokumentation und den Client-Flow, um die erwartete Token-Art festzulegen. Das Senden eines ID-Tokens an eine API kann selbst dann fehlschlagen, wenn seine Signatur für den Identitätsanbieter gültig ist. Die Dekodierung unterstützt die Diagnose; Es kann weder das Typenschild authentifizieren noch API-Berechtigungen erteilen.
kid nach der Schlüsselrotation – ein gültiges Token, das auf einen Schlüssel verweist, den der Server nicht mehr hat
Nach der Schlüsselrotation kann sich ein Header `kid` auf einen Schlüssel beziehen, der im aktuellen vertrauenswürdigen Satz des Servers fehlt. Lesen Sie die Kennung und überprüfen Sie dann die Cache- und Schlüsselsatzprotokolle auf dem Verifizierer. Rufen Sie keine im Header bereitgestellte URL ab und akzeptieren Sie kein eingebettetes Schlüsselmaterial als schnelle Problemumgehung.
Ein korrekt signiertes Token kann immer noch fehlschlagen, wenn der Prüfer den zulässigen Schlüssel nicht finden kann, während ein Angreifer einen beliebigen `kid` in einen nicht überprüften Header schreiben kann. Der Wert ist ein Suchhinweis, der durch die Konfiguration des vertrauenswürdigen Ausstellers eingeschränkt wird, und kein Beweis dafür, dass ein bestimmter Schlüssel geglaubt werden sollte.
Funktioniertes Beispiel – Ausführen eines abgelehnten Tokens durch die Checkliste im ToolAcre JWT-Decoder
Für eine funktionierende Triage nehmen Sie ein kontrolliertes abgelehntes Token, bestätigen drei Segmente, prüfen Fehler und zeichnen dann `exp`, `nbf`, `aud`, `iss`, `typ` und `kid` auf, ohne es zu bearbeiten. Vergleichen Sie jedes Feld mit der Ziel-API der Anfrage und der vertrauenswürdigen Konfiguration des Prüfers. Halten Sie Serverprotokolle für die tatsächliche Fehlerkategorie geöffnet.
Wenn alle sichtbaren Werte wie erwartet aussehen, schließen Sie nicht, dass die API falsch ist. Signaturbeschädigung, falsches Schlüsselmaterial, widerrufener Status oder nicht angezeigte Richtlinie können immer noch die Ursache für 401 sein. ToolAcres `signatureVerified` bleibt falsch, unabhängig davon, wie ordentlich JSON erscheint.
Was dies nicht abdeckt und das Fazit: Ein Decoder kann Ihnen nicht sagen, ob die Signatur gültig ist; Die Checkliste findet Anspruchsprobleme und Signaturfehler erfordern Serverprotokolle
Ein Decoder kann Ihnen nicht sagen, ob die Signatur gültig ist. Die Schadenscheckliste findet Kopier- und Nutzlastprobleme, die ohne Schlüssel sichtbar sind. Signaturfehler und maßgebliche Richtlinienentscheidungen erfordern Serverbeweise. Behandeln Sie eine Dekodierung als eine diagnostische Beobachtung unter mehreren.
Der schnellste zuverlässige Pfad ist geordnet: Antwortkontext beibehalten, Tokenform prüfen, Zeiteinheiten vergleichen, dann Aussteller, Zielgruppe, Typ und Schlüsselkennung mit vertrauenswürdiger Konfiguration vergleichen. Hören Sie mit dem Vertrauen auf, bis der echte Verifizierer die Kryptografie und die Richtlinien bestätigt.