Im vergangenen Frühjahr haben sich die Benutzer von toolz.dev angemeldet. Nicht manchmal - ständig. Anmelden, klicken Sie auf ein Tool, Boom: Zurück zum Anmeldebildschirm. Das Backend gibt 15-minütige Zugriffstoken und 7-Tage-Aktualisierungstoken aus, und ich habe diesen Flow hundert Mal getestet. Also nahm ich an, dass der Refresh-Endpunkt kaputt war und verbrachte eine Stunde und vierzig Minuten damit, Express-Middleware zu lesen, die nichts falsch daran hatte.
Dann habe ich endlich das Offensichtliche getan. Ich habe ein Live-Zugriffstoken aus dem Autorisierungs-Header gepackt, in einen Decoder eingefügt und die Ansprüche angesehen. der exp War in Ordnung. der iat War in Ordnung. Der Token war weitere 14 Minuten gültig. Was bedeutete, dass der Server in Ordnung war - und der Fehler musste auf dem Client sein. Sicher genug: Mein Frontend überprüfte payload.exp < Date.now()drohen exp ist Sekunden seit Epoche. Date.now() ist Millisekunden. Jeder frisch geprägte Token sah so aus, als wäre er um 1970 abgelaufen, also meldete der Kunde "hilfreich" alle aus, bevor der Server jemals mitreden konnte. Drei Zeichen von Fix - /1000 - Nach fast zwei Stunden Jagd.
Das ist die ganze Tonhöhe für einen JWT-Decoder in Ihrer Toolbox. Ein JWT sieht aus wie Liniengeräusche - drei Stücke Base64url-Kauderwelsch, die mit Punkten zusammengeklebt sind - aber es ist nur JSON, der einen Trenchcoat trägt. In dem Moment, in dem Sie die Behauptungen lesen können, sind die Hälfte Ihrer Authentifizierungsfehler nicht mehr als Geheimnisse. Falsches Publikum, abgelaufener Token, fehlende Rolle, Uhrverzerrung, Millisekunden-gegen-Sekunden - sie sitzen alle genau dort im Klartext, sobald Sie die Dekodierung haben.
Aber - und das ist wichtig - wo Sie dekodieren, ist keine neutrale Wahl. Ein echter Zugriffstoken ist ein Live-Credential. Fügen Sie es in eine Decoder-Site ein, die Token an einen Server sendet, und Sie haben gerade einen funktionierenden Schlüssel für Ihre API in die Anfrageprotokolle eines Fremden hinterlegt. Das ist der spezifische Grund, warum ich das gebaut habe toolz.dev JWT-Decoder vollständig in Ihrem Browser ausgeführt werden. Mehr dazu unten.
tl; dr: Um ein JWT online zu dekodieren, fügen Sie es in die toolz.dev JWT-Decoder — Es teilt Kopfzeile, Nutzlast und Unterschrift sofort, übersetzt
exp/iatin menschliche Daten und läuft zu 100% clientseitig, sodass der Token Ihre Maschine niemals verlässt. Eine Sache, die in den Speicher brennt: Dekodierung ist nicht zu überprüfen. Ein JWT ist nur base64url-kodierte JSON, die jeder lesen kann - nur die Signaturüberprüfung mit dem Schlüssel beweist, dass er vertrauenswürdig ist.
Hauptmerkmale
Sofortiger Kopf, Nutzlast und Signaturaufteilung
Fügen Sie einen Token ein und der Decoder unterteilt ihn sofort in seine drei Teile: den Kopf (Algorithmus und Tokentyp), die Nutzlast (Ihre Ansprüche) und die Signatur (links codiert, da es sich um einen rohen Mac oder eine Signatur handelt - es gibt dort nichts, was menschlich lesbar ist). Keine Schaltfläche zum Absenden, kein Neuladen der Seite. Dies spiegelt genau das wider, was Ihre Auth-Bibliothek intern vor der Überprüfung tut: Aufgeteilt ., base64url-dekodieren die ersten beiden Segmente, analysieren Sie als JSON. Die nebeneinander ausgelegten Teile sind der schnellste Weg, um die Intuition für das Format zu bauen. Nach ein paar Dutzend Tokens erkennen Sie auf einen Blick einen RS256-Auth0-Token im Vergleich zu einem HS256-Laravel-Token - der Header gibt ihn jedes Mal ab.
Von Menschen lesbare Exp-, IAT- und NBF-Zeitstempel
Die nützlichste Funktion, Punkt. exp, iat, und nbf sind numerische Werte - Sekunden seit der Unix-Epoche - und niemand, ich eingeschlossen, kann lesen 1783430700 Und sag dir, ob das am nächsten Dienstag oder der Hitzetod des Universums ist. Der Decoder wandelt jeden Zeitstempelanspruch in ein aktuelles Datum und eine aktuelle Uhrzeit in Ihrer lokalen Zeitzone und UTC um. Hier wird der klassische Millisekunden-gegen-Sekunden-Fehler sofort sichtbar: Wenn Sie dekodiert sind exp Rendert als Datum im Jahr 56.000-etwas, jemand hat ein Javascript gestopft Date.now() in ein Feld, das Sekunden erwartet. Ich habe diesen Fehler verschickt. Das absurde Datum zu sehen ist die Diagnose. Für die tiefere Zeitstempelarchäologie Zeitstempelkonverter ist eine Registerkarte entfernt.
Ablaufcountdown und Status
Der Decoder zeigt Ihnen nicht nur das Datum, sondern gibt Ihnen den aktuellen Status des Tokens an: gültig, abgelaufen oder noch nicht aktiv (wenn nbf ist in der Zukunft). Wenn der Token noch am Leben ist, erhalten Sie einen Countdown zum Ablauf. Dies klingt nach einer kleinen Bequemlichkeit, bis Sie einen intermittierenden 401 debuggen und "War dieser spezielle Token tot, als die Anfrage abgefeuert wurde?" "War immer wieder?" Der Vergleich des Countdowns mit der konfigurierten TTL-Server führt auch zu einer schnellen Fehlkonfiguration. Wenn Ihre Zugriffstoken 15 Minuten lang leben sollen und der Countdown 6 Tage lang anzeigt, liest Ihr Ausgabecode den falschen Konfigurationswert.
Algorithmus- und Header-Inspektion
Der dekodierte Header zeigt Ihnen alg und typ (plus kid und Freunde, wenn sie vorhanden sind), die Fragen beantworten, die für die Sicherheit von Bedeutung sind, nicht nur das Debuggen. ist das Token HS256 oder RS256? Tut das kid Passen Sie einen Schlüssel an, den Ihr JWKS-Endpunkt tatsächlich bedient? Und der große: ist alg etwas, das es niemals sein sollte, wie none? Tokens beanspruchen "alg": "none" Entweder Test-Fixtures oder jemand, der Ihren Verifizierer prüft - so oder so, Sie möchten ihn sofort sehen. Ich überprüfe zuerst den Header auf jedem unbekannten Token, bevor ich einen einzelnen Anspruch lese.
Syntax-hervorgehobene, formatierte JSON-Ansprüche
Rohe dekodierte Nutzlasten sind einzeilige JSON-Blobs, und Identitätsanbieter packen sie gerne: verschachtelte Objekte, benutzerdefinierte Namensräume, Arrays von Bereiche. Der Decoder druckt alles mit Syntax-Highlighting so roles, scope, aud Arrays und verschachtelte Berechtigungsobjekte sind tatsächlich scannbar. Es ist die gleiche Behandlung JSON-Formater Gibt willkürliche JSON, wird automatisch auf Ihre Ansprüche angewendet. Wenn Sie zwei Token vergleichen - beispielsweise eines von einem Benutzer, der auf einen Endpunkt zugreifen kann, und eines von einem Benutzer, der die Ausgabe kann -, macht die formatierte Ausgabe eine Schielenübung in einen 10-Sekunden-Diff.
100% clientseitig – Ihr Token verlässt den Browser nie
Dies ist die Funktion, für die ich kämpfen würde. Ein eingefügtes Zugriffstoken ist keine Beispieldaten – es ist ein Live-Credential, der sich als echter Benutzer authentifiziert expdrohen Jeder Decoder, der Ihr Token an ein Backend postet, hat gerade einen funktionierenden Schlüssel in Serverprotokolle, Analytics und möglicherweise einen Fehler-Tracker eines Drittanbieters geschrieben. Der Toolz.dev-Decoder führt die Dekodierung in JavaScript in Ihrem Tab durch. Es wird nichts übertragen, nichts wird gespeichert. Nehmen Sie mein Wort nicht: Öffnen Sie DevTools, sehen Sie sich die Registerkarte Netzwerk an, fügen Sie einen Token ein. Null Anfragen. Ich habe geschrieben, warum diese Architektur für jedes sensible Eingabetool in wichtig ist Mein Artikel zum Datenschutz in Online-Toolsdrohen
Funktioniert mit jedem JWT, von jedem Stapel
JWTs sind ein Standard - RFC 7519 - also ist es dem Decoder egal, wer Ihren geprägt hat. Auth0- und Firebase-Tokens mit ihren Namensräumen, Laravel Sanctum-benachteiligten Setups, Keycloak, Supapase, AWS Cognito oder den handgerollten HS256-Tokens Meine eigenen Express-Backend-Signes für Toolz.dev – wenn es die drei Base64URL-Segmente sind, die durch Punkte verbunden sind, entschlüsselt es. Dazu gehören fehlerhafte fast-JWTs: Wenn das Segment zwei nicht als JSON analysiert wird, sagt Ihnen der Decoder, welcher Teil kaputt ist, anstatt still zu scheitern, was selbst diagnostisch ist. Tokens auf Kopierer sind häufiger als Sie denken.
Wie man den JWT-Decoder verwendet
Schritt 1: Schnappen Sie sich den Token
Finden Sie den Token, wo immer Ihre App ihn aufbewahrt. Am häufigsten: DevTools → Registerkarte Netzwerk → Klicken Sie auf eine Anfrage → Kopieren Sie die Authorization: Bearer eyJ... Kopfwert (ohne das Wort "Bearer"). Oder checken Sie die Anwendung → Lokaler Speicher / Cookies, da dort viele Apps stecken. Melden Sie es am Backend an oder ziehen Sie es aus Ihrer Testsuite. Kopieren Sie die gesamte Zeichenfolge - ein JWT, das seine letzten Zeichen verliert, dekodiert, aber nie überprüft, und das ist eine verwirrende Stunde, die Sie nicht benötigen.
Schritt 2: Füge es ein
Öffne das JWT-Decoder und einfügen. Die Dekodierung erfolgt während der Eingabe - keine Schaltfläche. Wenn Sie nervös sind, einen Produktions-Token irgendwo einzufügen (guter Instinkt), öffnen Sie zuerst die Registerkarte Netzwerk und bestätigen Sie, dass nichts übertragen wird. es ist nicht. Dieser Paranoia-Check dauert zehn Sekunden und genau das, was ich mit jemand anderem tun würde.
Schritt 3: Lesen Sie die drei Teile
Header zuerst: Bestätigen alg ist das, was Ihr System erwartet und typ ist JWTdrohen Dann die Nutzlast: iss (Wer hat es geprägt), aud (Wen es ist) sub (welcher Benutzer) plus welche Rollen, Bereiche oder benutzerdefinierten Ansprüche Ihr Stack hinzufügt. Die Signatur bleibt verschlüsselt – sie ist kryptografische Ausgabe, nicht Daten. Wenn der Header sagt none, Stoppen Sie und überprüfen Sie Ihre Prüfliste vor allem.
Schritt 4: Überprüfen Sie exp und die Behauptungen, die beißen
Schau dir die dekodierten an exp Datum und Ablaufstatus. abgelaufen? Es ist dein 401. gültig, aber trotzdem abgelehnt? Jetzt vergleichen aud und iss Gegen die Konfiguration Ihrer Verifizierer - Mismatches gibt es die zweithäufigste Ursache nach dem Ablauf. Und wenn ein Zeitstempel als fünfstelliges Jahr gerendert wird, herzlichen Glückwunsch: Sie haben einen Millisekunden-gegen-Sekunden-Fehler gefunden und ich heiße Sie hiermit in einem sehr großen Club willkommen.
Was steckt eigentlich in einem JWT? Anatomie der drei Teile
Ein in RFC 7519 definiertes JSON-Web-Token besteht aus drei base64URL-codierten Segmenten, die durch Perioden verbunden sind: header.payload.signaturedrohen (Stengtimiert ist die signierte Sorte ein JWS pro RFC 7515 - es gibt einen verschlüsselten Cousin, JWE, aber fast jeder Token, den Sie in der Wildnis treffen werden, ist ein signierter JWs.)
Das Schlüsselwort ist verschlüsseltdrohen Base64URL ist eine Transportkodierung - eine reversible Methode, um Bytes URL-sicher zu machen - und nicht Verschlüsselung. Jeder, der ein JWT besitzt, kann alles im Header und in der Nutzlast mit Null-Schlüssel, Null-Geheimnissen und Nullaufwand lesen. Spielen Sie mit der RAW-Codierung in der Base64-Konverter Und Sie werden sehen, dass es das Standardalphabet mit ist + und / gegen getauscht - und _, Polsterung fallen gelassen. Ich habe mehr über die Codierung selbst geschrieben Base64-Codierungshandbuchdrohen
Dekodieren Sie einen typischen Header und Sie erhalten:
{ "alg": "HS256", "typ": "JWT" }
und eine aus den registrierten Ansprüchen RFC 7519 erstellte Nutzlast definiert:
{
"iss": "https://toolz.dev",
"sub": "user_8f3a2c",
"aud": "toolz-api",
"exp": 1783431600,
"nbf": 1783430700,
"iat": 1783430700,
"jti": "b4d1f0e2"
}
iss ist der Emittent, sub das Thema (in der Regel Ihre Benutzer-ID), aud das beabsichtigte Publikum, jti Eine eindeutige Token-ID. exp, nbf, und iat sind numerische Werte: Sekunde Seit der Unix-Epoche. nicht Millisekunden. Date.now() Gibt Millisekunden zurück und verwirren die beiden Produzieren entweder Token, die sofort ablaufen (mein toolz.dev-Abmeldefehler) oder Token mit exp Daten im Jahr 56.000, die effektiv nie verfallen - was der gefährlichere Fehler ist.
HS256 gegen RS256. HS256 unterschreibt mit einem HMAC über ein gemeinsames Geheimnis - schnell, einfach, aber jeder Dienst, der Token überprüft, hält auch das Geheimnis, und jeder, der das Geheimnis hält, kann Münzanstalt Tokens. Gut für einen Monolith wie mein Backend, bei dem der Emittent und der Verifizierer der gleiche Prozess sind. RS256 signiert mit einem privaten Schlüssel und überprüft mit einem öffentlichen Schlüssel, sodass Sie den öffentlichen Schlüssel (über JWKS) veröffentlichen und ein Dutzend Mikrodienste überprüfen lassen können, ohne dass einer von ihnen in der Lage ist, ihn zu fälschen. Verteilte Systeme und IDPs von Drittanbietern sollten sich auf RS256 oder ihren ECDSA / EDDSA-Geschwistern befinden.
der alg: none angreifen RFC 7519 erlaubt ungesicherte JWTs, wo alg ist none Und die Signatur ist leer. Frühe Bibliotheken vertrauten dem Header alg Blind, also strippten Angreifer die Signatur aus, Set alg auf none, und segelte durch Verifizierung mit vollständig von Angreifern kontrollierten Ansprüchen. Ein verwandter Trick tauscht RS256 gegen HS256, sodass der Verifizierer die öffentlich Schlüssel als HMAC-Geheimnis. Aus diesem Grund ist RFC 8725 - JSON Web Token Best-Practices - ist stumpf: Der Verifizierer muss seine zulässigen Algorithmen im Code feststecken und den Token niemals wählen lassen. Wenn Ihr Bibliotheksaufruf keine explizite enthält algorithms Liste, beheben Sie das heute.
Dekodierung vs. Verifizieren – die Linie, die zählt. Dekodierung ist Lesen, Verifizieren ist vertrauenswürdig. Der Unterschied im Code:
// Decoding: no secret, no trust. Anyone can do this.
const payload = JSON.parse(
Buffer.from(token.split('.')[1], 'base64url').toString()
);
// Verifying: proves the signature AND pins the algorithm.
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });
Ein Online-Decoder macht das erste. Es kann Ihnen die Behauptungen zeigen, es kann und sollte nicht so tun, als ob es authentisch ist. nur verify, mit dem Schlüssel, das tut. Treffen Sie niemals Autorisierungsentscheidungen von dekodierten, aber nicht verifizierten Ansprüchen.
Was zur letzten Regel führt: Setzen Sie niemals Geheimnisse in eine JWT-Nutzlast. Keine Passwörter, keine API-Schlüssel, keine Daten, die Sie bei einem Angreifer lesen. Die Nutzlast ist durch Bauwesen öffentlich - unterzeichnet gegen Manipulation, weit offen für Lesen. Wenn es sich um das Token handelt, nehmen Sie an, dass das gesamte Internet es sehen kann.
Häufige Anwendungsfälle
Debuggen von 401s während der API-Entwicklung
Der 401 ist der am wenigsten informative Statuscode in HTTP. Der Server sagte nein - aber war der Token abgelaufen? Falsches Publikum? Mit einem abgestandenen Schlüssel signiert? Vermisst ganz, weil Ihr Abfangjäger nicht gefeuert hat? Das Dekodieren des eigentlichen Tokens aus der fehlgeschlagenen Anforderung klappt in Sekundenschnelle den Suchbereich. halbe Zeit exp beantwortet es allein. die andere Hälfte, vergleichen iss und aud In der Umgebung Ihres Verifizierers wird die Konfiguration von einem Dev-Token gegen Staging oder umgekehrt wiederholt. Ich halte den Decoder neben meinem HTTP-Client für genau diese Schleife fest; es ist ein Kerneintrag in meinem API-Debugging-Toolkitdrohen Dekodieren Sie zuerst, lesen Sie Middleware und dann - die umgekehrte Reihenfolge hat mich einmal eine Stunde und vierzig Minuten gekostet, und ich beabsichtige, weiterhin Interesse an dieser Lektion zu sammeln.
Erklären Sie Überraschungsabmeldungen
Wenn Benutzer "Es meldet mich immer wieder aus", "Die Zeitstempel des Tokens sind Ihre Zeugenaussage. Dekodieren Sie ein neues Zugriffstoken und überprüfen Sie die Lücke zwischen iat und exp - Sind es tatsächlich die 15 Minuten, die Sie konfiguriert haben, oder hat ein Env-VAR es auf 60 Sekunden überschrieben? Überprüfen Sie dann, ob das 7-Tage-Fenster des Aktualisierungs-Tokens das ist, was Sie denken. Auch hier taucht die Uhrverzerrung auf: Wenn die Uhr Ihres ausstellenden Servers ein paar Minuten schnell läuft, kommen Tokens schon uralt durch die Kundenberechnung an. Und natürlich kündigt sich der Vergleichsfehler von Sekunden-gegen-Millisekunden - der Bit toolz.dev - an, sobald Sie eine vollkommen gültige sehen exp Auf einem Token ist Ihr Kunde abgelaufen.
Auditing, was Ihr Identitätsanbieter in Token einsetzt
Die meisten Teams haben die Tokens ihrer IDP-Mints nie gelesen, und es lohnt sich, sie zu tun. Wenn Sie eine dekodieren, finden Sie möglicherweise E-Mail-Adressen, vollständige Namen, Bild-URLs, Mandantenkennungen - PII, die in jeder einzelnen API-Anfrage mitgespielt werden, in LocalStorage gespeichert und von allem lesbar, was die Hände auf dem Token lesbar ist. Hier ist meine Meinung, und ich werde es mit jedem argumentieren: Setzen Sie keine Benutzer-E-Mails in JWT-Nutzdaten ein. der sub Der Anspruch besteht genau, damit Sie eine undurchsichtige Kennung tragen und die menschlichen Details auf der Serverseite nachschlagen können. Jeder zusätzliche Anspruch sind Daten, die Sie senden, und Bytes, für die Sie bei jeder Anfrage bezahlen. Dekodieren, prüfen und dann die Anspruchszuordnungen Ihrer IDP kürzen.
Überprüfen von Rollen und Bereichen während der Autorisierungsdebugging
Authentifizierung sagt, wer Sie sind; Autorisierung sagt, was Sie tun können - und wenn sich die Autorisierung schlecht verhält, ist die Antwort in den Ansprüchen. Der Benutzer schwört, dass sie ein Administrator sind, aber 403er bekommen? Dekodieren Sie ihr Token. insofern role verkündet userDer Token wurde vor der Aktion geprägt und sie müssen sich erneut anmelden - eine klassische Folge von zustandslosen Tokens, die veraltete Schnappschüsse tragen. Wenn die Rolle vorhanden ist, der Zugriff jedoch immer noch fehlschlägt, überprüfen Sie den genauen Anspruchsnamen und die Form: roles Vs role, Array gegen String, scope als space-delimited String vs. scp als Array. Middleware-Prüfung payload.roles.includes('admin') gegen eine Nutzlast, die hat role: "admin" scheitert lautlos und ärgerlich. Zwei dekodierte Token nebeneinander - einer arbeiten, einer nicht - regeln normalerweise in weniger als einer Minute.
Vergleichen von Zugriffs- und Aktualisierungsinhalten
In einem Dual-Token-Setup wie meinem sollten die beiden Tokens sinnvoll anders aussehen, und die Dekodierung beider ist das Audit. Das Zugriffstoken: kurz exp, plus was auch immer die API pro Anfrage benötigt. Das Aktualisierungs-Token: lang exp, a jti für die Widerrufsverfolgung und so nahe wie möglich an nichts anderem. Wenn Ihr Aktualisierungstoken Rollen und Profildaten enthält, ist etwas nicht vorhanden - es wird immer nur einem Endpunkt präsentiert und sollte den Job des Zugriffstokens nicht duplizieren. Dieser Side-by-Side-Check fängt auch die peinliche Bug-Klasse ein, in der beide Token versehentlich die gleiche TTL erhalten, was Ihr "15-minütiges Zugriffsfenster" in Sicherheitstheater verwandelt. Fragen Sie mich, woher ich weiß, ob ich das überprüfen soll.
JWT vs. undurchsichtige Sitzungs-Token: Ein ehrlicher Vergleich
| Jouunterstrich | Undurchsichtiger Sitzungstoken | |
|---|---|---|
| Staatenlosigkeit | in sich geschlossen; jeder Server mit dem Schlüssel überprüft ohne Nachschlagen | Server (oder Shared Store wie Redis) muss jede Anfrage nachschlagen |
| Widerruf | hart - gültig bis exp Es sei denn, Sie bauen eine Denylist, die den Zustand wieder einführt |
Trivial — Löschen Sie den serverseitigen Datensatz, Token stirbt sofort |
| Größe pro Anfrage | Hunderte von Bytes bis über ein Kilobyte, jeder Antrag | ~32–64 Bytes |
| Wo Validierung erfolgt | Überall mit der (öffentlichen) Taste – ideal für Microservices | Wo immer der Sitzungsladen lebt |
| Frische beanspruchen | Snapshot zum Ausgabezeitpunkt; Rollenänderungen warten auf erneute Ausgabe | Immer aktuell - Liest Live-Daten |
| Debuggbarkeit | Ansprüche sofort dekodieren und lesen | Opak durch Design; erfordert den Zugriff auf den Laden |
Ich benutze JWTs für toolz.dev und sage Ihnen immer noch, dass sie überprobiert sind. Die Widerrufsgeschichte ist wirklich schlecht: Wenn Sie einen Benutzer bannen, funktioniert sein Zugriffstoken bis exp - Genau deshalb leben meine Zugriffstoken 15 Minuten und das 7-Tage-Aktualisierungs-Token ist das, was ich auf der Serverseite töten kann. Dieser Hybrid ist das ehrliche Muster: kurzlebige staatenlose JWTs für die billige Verifizierung, ein staatlicher Kontrollpunkt für die Kontrolle. Wenn Sie einen Monolith mit einer Datenbank ausführen, sind einfache Sitzungen einfacher, kleiner und sofort widerrufbar. Die Superkraft der verteilten Verifizierung löst ein Problem, das Sie nicht haben.
Während wir vergleichen - HS256 vs RS256 auf einen Blick:
| HS256 | RS256 | |
|---|---|---|
| Schlüsselmodell | Ein gemeinsames geheimes Zeichen und verifizieren | Private Schlüsselzeichen, öffentlicher Schlüssel überprüft |
| Wer kann Tokens prägen | Jeder, der das Geheimnis hält | Nur der private Schlüsselhalter |
| am besten passen | Einzelservice, Emittent = Verifizierer | Microservices, IDPs von Drittanbietern, JWKs |
| Signaturgröße / Geschwindigkeit | kleiner, schneller | Größer, langsamer, sicherer zu verteilen |
Häufig gestellte Fragen
Ist es sicher, ein JWT in einen Online-Decoder einzufügen?
Nur wenn der Decoder clientseitig läuft. Ein echter Token ist ein Live-Anmeldeinformationen - das Senden an einen Server plant einen funktionierenden Schlüssel in seinen Protokollen. Der Toolz.dev JWT-Decoder übernimmt die Dekodierung in Ihrem Browser und überträgt nichts, das können Sie selbst bestätigen, indem Sie sich beim Einfügen auf die Registerkarte Netzwerk gucken. Bei Decodern können Sie nicht überprüfen, nur abgelaufene oder Test-Token verwenden.
Können Sie ein JWT ohne das Geheimnis entschlüsseln?
Ja - das ist der Punkt, den die Leute am meisten vermissen. Der Header und die Nutzlast sind base64URL-codiert JSON, und die Codierung ist keine Verschlüsselung. Jeder kann jeden Anspruch ohne Schlüssel lesen. Der Geheimnis (oder privater Schlüssel) wird nur zum Erstellen oder Verifizieren der Signatur benötigt. Dekodierung erfordert nichts, Vertrauen erfordert Überprüfung.
Was ist der Unterschied zwischen der Dekodierung und dem Verifizieren eines JWT?
Decodierung liest den Inhalt: Aufgeteilt auf Punkte, base64url-decode, parse JSON. Überprüfung der Authentizität: Berechnen oder überprüfen Sie die Signatur mit dem geheimen oder öffentlichen Schlüssel, bestätigen Sie den Algorithmus und überprüfen Sie den Ablauf. Ein Decoder zeigt Ihnen, was ein Token behauptet, nur die Verifizierung, die mit dem Schlüssel erfolgt, sagt Ihnen, ob Sie es glauben sollen. Autorisieren Sie niemals basierend auf dekodierten, aber nicht verifizierten Ansprüchen.
Warum wird mein JWT als ungültig oder abgelaufen angezeigt?
am häufigsten die exp hat es wirklich bestanden - dekodieren und das Datum überprüfen. Nächste Verdächtige: Ein abgeschnittenes Token aus einer schlampigen Kopier-Einfügung, ein aud oder iss Das entspricht nicht der Konfiguration Ihrer Verifizierer, der Uhrverzerrung zwischen Servern oder einer Signatur eines gedrehten Schlüssels. Wenn das dekodiert exp Sieht gut aus, aber Ihr Code lehnt den Token ab. Überprüfen Sie, ob Sie Sekunden mit Millisekunden vergleichen.
Sind JWTs verschlüsselt?
Standard-JWTs - technisch gesehen JWs gemäß RFC 7515 - sind signiert und nicht verschlüsselt. Die Signatur erkennt Manipulationen, verbirgt aber nichts, die Nutzlast ist von jedem lesbar. Eine verschlüsselte Variante (JWE) existiert, ist aber in der typischen Web-Authentifizierung selten. Praktische Regel: Behandeln Sie jede JWT-Nutzlast als öffentlich und fügen Sie niemals Kennwörter, API-Schlüssel oder sensible Daten in einen ein.
In welchem Format ist der EXP-Anspruch?
exp ist ein numerisches Datum: Sekunden seit der Unix-Epoche (1. Januar 1970 UTC), wie in RFC 7519 definiert. Gleich für iat und nbfdrohen Der klassische Fehler ist die Verwendung von Javascript Date.now(), die Millisekunden zurückgibt - Erzeugt Tokens, die entweder sofort abgelaufen sind oder Ablaufdaten um das Jahr 56.000 tragen. Wenn ein dekodierter Zeitstempel ein fünfstelliges Jahr anzeigt, ist dies Ihr Fehler.
Was ist der ALG-Angriff?
RFC 7519 erlaubt ungesicherte JWTs mit "alg": "none" und eine leere Unterschrift. Alte Bibliotheken vertrauten dem Feld des Header-Algorithmus, so dass Angreifer Signaturen streiften, gesetzt alg auf none, und bestandene Überprüfung mit gefälschten Ansprüchen. RFC 8725, die Best Practices für JWT, erfordert, dass Verifizierer eine explizite Zulässigkeitsliste von Algorithmen im Code anheften und ignorieren, was der Token verlangt.
Soll ich HS256 oder RS256 verwenden?
HS256 verwendet ein gemeinsames Geheimnis zum Signieren und Verifizieren - einfach und schnell, genau richtig für einen einzelnen Dienst, der seine eigenen Token ausgibt und überprüft. RS256 signiert mit einem privaten Schlüssel und überprüft mit einem öffentlichen, so dass viele Dienste dies überprüfen können, ohne dass sie fälschen können. Faustregel: Monolith, HS256; Microservices oder Drittanbieter-Identitätsanbieter, RS256.
Abschluss
Ich habe das gebaut JWT-Decoder Weil ich es immer wieder gebraucht habe, während ich Toolz.dev selbst erstellt habe - dieselben 15-minütigen Zugriffstoken und 7-tägige Aktualisierungstoken, die ich in diesem Handbuch untersucht habe. Es dekodiert sofort, übersetzt die Zeitstempel, die 90% der Verwirrung verursachen, und sendet Ihren Token nie irgendwohin. Dieser letzte Teil ist kein Feature-Checkbox; für ein Tool, das Live-Anmeldeinformationen verarbeitet, ist es das gesamte Design.
Wenn Token Teil Ihres täglichen Debuggens sind, verdienen die Nachbarn auch ihren Aufenthalt: Die Zeitstempelkonverter Für die Epochenarchäologie Base64-Konverter Zum Stochern in RAW-Segmenten JSON-Formater für Anspruchsblobs und die Hash-Generator Wenn Sie mit Digests arbeiten. Für den breiteren Workflow meine API-Debugging-Tools Deckt ab, wo ein Decoder in die Schleife passt.
Und lassen Sie die One-Sentence-Version auf Ihren Monitor aufgezeichnet: Decodierung zeigt Ihnen, was ein Token sagt, die Überprüfung zeigt Ihnen, ob Sie es glauben sollen. Verwirren Sie die beiden und Sie werden die Art von Fehler versenden, die als Eröffnungsanekdote in einem Blog-Beitrag von jemandem endet. Diesmal war es meins.
