JWT-Decoder online: Dekodieren, prüfen und verstehen Sie Ihre Token

Im letzten Frühjahr begannen Benutzer, sich von Toolz.dev abzumelden Nicht manchmal - ständig Anmelden, ein Tool anklicken, zack: zurück zum Anmeldebildschirm Das Backend gibt 15-Minuten-Zugriffstoken und 7-Tage-Aktualisierungstoken aus, und I' d testete den Ablauf hundertmal. Daher ging ich natürlich davon aus, dass der Refresh-Endpunkt kaputt war, und verbrachte eine Stunde und vierzig Minuten damit, Express-Middleware zu lesen, an der nichts auszusetzen war.

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 noch 14 Minuten gültig, was bedeutete, dass der Server in Ordnung war - und der Bug auf dem Client sein musste Sicher genug: Mein Frontend checkte payload.exp < Date.now()drohen exp ist Sekunden seit Epoche. Date.now() Millisekunden ist Jeder frisch geprägte Token sah aus, als wäre er irgendwo um 1970 abgelaufen, also hat der Client & quot; hilfsbereit" alle abgemeldet, bevor der Server jemals ein Mitspracherecht bekam Drei Zeichen Fix - /1000- nach fast zwei Stunden Jagd.

That' s die ganze Tonhöhe, um einen JWT-Decoder in Ihrer Toolbox zu haben Ein JWT sieht aus wie Zeilenrauschen - drei Brocken Base64url-Kauderwelsch, die mit Punkten zusammengeklebt sind - aber es's nur JSON trägt einen Trenchcoat In dem Moment, in dem Sie die Behauptungen lesen können, hören die Hälfte Ihrer Autorenfehler auf, Geheimnisse zu sein Falsches Publikum, abgelaufener Token, fehlende Rolle, Uhrspieß, Millisekunden-gegen-Sekunden - sie #39; sitzen alle genau dort im Klartext, sobald Sie dekodiert haben.

Aber - und das ist wichtig - wo Sie dekodieren, ist keine neutrale Wahl Ein echtes Zugriffstoken ist ein Live-Anmeldeinformationen Fügen Sie es in eine Decoder-Site ein, die Token an einen Server sendet, und Sie' haben gerade einen funktionierenden Schlüssel zu Ihrer API in ein fremdes & #39; s-Anfrageprotokoll hinterlegt. That' ist der konkrete Grund, warum ich das erstellt 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 Header, Nutzlast und Signatur sofort auf und übersetzt exp/iat In menschliche Datteln, und läuft 100% client-seitig, so dass das Token nie Ihre Maschine verlässt Eine Sache, um in den Speicher zu brennen: Decodierung ist NICHT verifizieren Ein JWT ist nur base64url-codiertes JSON, das jeder lesen kann - nur die Signaturverifizierung mit dem Schlüssel beweist es & #39; s vertrauenswürdig.

Hauptmerkmale

Sofortiger Kopf, Nutzlast und Signaturaufteilung

Fügen Sie ein Token ein und der Decoder zerlegt es sofort in seine drei Teile: den Header (Algorithmus und Token-Typ), die Nutzlast (Ihre Ansprüche) und die Signatur (links codiert, denn es' s ein Roh-MAC oder eine Signatur - da und #39; s nichts Menschenlesbares drin).Kein Submit-Button, kein Seiten-Neuladen Das spiegelt genau das wider, was Ihre Autorenbibliothek intern vor der Verifizierung tut: aufteilen .Basis64url-dekodieren die ersten beiden Segmente, analysieren als JSON Die nebeneinander angeordneten Teile zu sehen ist der schnellste Weg, Intuition für das Format aufzubauen Nach ein paar Dutzend Tokens beginnen Sie' auf einen Blick ein RS256 Auth0 Token gegenüber einem HS256 Laravel Token zu erkennen - der Header verrät es jedes Mal.

Von Menschen lesbare Exp-, IAT- und NBF-Zeitstempel

Die nützlichste Funktion, Punkt. exp, iat, und nbf NumericDate-Werte sind - Sekunden seit der Unix-Epoche - und niemand, ich selbst 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 das Token's noch lebt, erhalten Sie einen Countdown bis zum Ablauf Das klingt nach einer kleinen Bequemlichkeit, bis Sie're ein intermittierendes 401 debuggen und " beantworten müssen. War dieses spezielle Token tot, als die Anfrage ausgelöst wurde?" immer wieder vorbei Vergleichen des Countdowns mit Ihrem Server's konfiguriertem TTL fängt auch eine Fehlkonfiguration schnell auf - wenn Ihre Zugriffstoken 15 Minuten lang leben sollen und der Countdown 6 Tage angibt, liest Ihr ausstellender Code 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" Sind entweder Test-Leuchten oder jemand, der Ihren Prüfer untersucht - so oder so, Sie wollen es sofort sehen Ich überprüfe zuerst die Kopfzeile auf jedem unbekannten Token, bevor ich einen einzelnen Claim 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 Beliebiges JSON gibt, automatisch auf Ihre Ansprüche angewendet Wenn Sie' re zwei Token vergleichen - sagen wir, eines von einem Benutzer, der auf einen Endpunkt zugreifen kann und eines von einem Benutzer, der can' t - formatierte Ausgabe verwandelt eine Schielübung in ein Zehn-Sekunden-Diff.

100% Client-Seite - Ihr Token verlässt nie den Browser

Dies ist die Funktion, für die I & #39; d kämpft Ein eingefügter Zugriffstoken sind keine Beispieldaten - it& #39; s eine Live-Anmeldeinformation, die sich als echter Benutzer authentifiziert, bis 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 der Decoder tut' es ist egal, wer Ihre geprägt hat Auth0- und Firebase-Token mit ihren benutzerdefinierten Ansprüchen im Namensraum, an Laravel Sanctum angrenzenden Setups, Keycloak, Supabase, AWS Cognito oder den handgerollten HS256-Tokens meinen eigenen Express-Backend-Zeichen für Toolz.dev - wenn it's drei Basen64url-Segmente durch Punkte verbunden, dekodiert es. Dazu gehören fehlerhafte Fast-JWTs: Wenn Segment zwei won't als JSON analysiert, sagt Ihnen der Decoder, dass Sie stillschweigender sind.

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... Header-Wert (ohne das Wort & quot; Bearer").Oder Anwendung → Lokaler Speicher / Cookies überprüfen, da dort viele Apps Token verstauen, im Backend protokollieren oder aus Ihrer Testsuite ziehen Kopieren Sie die gesamte Zeichenfolge - ein JWT, der seine letzten Zeichen noch dekodiert, aber nie verifizieren wird, und das' s eine verwirrende Stunde, die Sie nicht brauchen & #39;t.

Schritt 2: Füge es ein

Öffne das JWT-Decoder Und einfügen.Dekodieren geschieht, während Sie eingeben - keine Taste Wenn Sie' nervös sind, irgendwo einen Produktionstoken einzufügen (guter Instinkt), öffnen Sie zuerst die Registerkarte Netzwerk und bestätigen Sie, dass nichts übertragen wird Es ist' t. Diese Paranoia-Prüfung dauert zehn Sekunden und it's genau das, was I' d auf jemand anderem machen's-Tool.

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 Stapel hinzufügt Die Signatur bleibt codiert - it's kryptografische Ausgabe, keine 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 Ihren Verifier' s config - nicht übereinstimmen gibt es die zweithäufigste Ursache nach Ablauf Und wenn irgendein Zeitstempel als fünfstelliges Jahr rendert, herzlichen Glückwunsch: you' haben einen Millisekunden-gegen-Sekunden-Bug gefunden, und ich begrüße Sie hiermit in einem sehr großen Club.

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.signature(Streng genommen ist die signierte Sorte ein JWS gemäß RFC 7515 - dort's ein verschlüsselter Cousin, JWE, aber fast jedes Token, das Sie und #39; in freier Wildbahn treffen, ist ein signierter JWS.)

Das Schlüsselwort ist verschlüsselt. Base64url ist eine Transportkodierung - eine reversible Möglichkeit, Bytes URL-sicher zu machen - keine Verschlüsselung Jeder, der eine JWT hält, kann alles im Header und in der Nutzlast mit null Schlüsseln, null Geheimnissen, null Aufwand lesen Spielen Sie mit der Rohkodierung 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 praktisch nie ablaufen - was im Stillen der gefährlichere Misserfolg ist.

HS256 gegen RS256. HS256 unterschreibt mit einem HMAC über ein gemeinsames Geheimnis - schnell, einfach, aber jeder Dienst, der Token überprüft, birgt auch das Geheimnis, und jeder, der das Geheimnis in sich trägt, kann es 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 Current Practices - unverblümt: Der Prüfer muss seine zulässigen Algorithmen in Code pinnen und darf das Token niemals wählen lassen Wenn Ihr Bibliotheksaufruf nicht #39; nicht explizit enthalten algorithms Liste, beheben Sie das heute.

Dekodieren vs. Verifizieren - die Zeile, 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 - Ihnen sagen, dass der Token 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 Sie' d wohlgemerkt ein Angreifer liest Die Nutzlast ist von Konstruktion öffentlich - gegen Manipulation signiert, weit offen für das Lesen Wenn es's im Token, nehmen Sie an, das ganze Internet kann es sehen.

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? fehlt ganz, weil Ihr Abfangjäger hat & #39;t feuern? durch Dekodieren des eigentlichen Tokens aus der fehlgeschlagenen Anfrage bricht der Suchraum in Sekunden zusammen Die Hälfte der 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-Toolkit. Zuerst dekodieren, Middleware-Sekunde lesen - die umgekehrte Reihenfolge kostete mich einmal eine Stunde und vierzig Minuten, 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? dann prüfen Sie, ob das Aktualisierungs-Token' s 7-Tage-Fenster das ist, was Sie denken Der Taktversatz wird auch hier angezeigt: Wenn Ihre Ausgabe-Server's-Uhr ein paar Minuten schnell läuft, kommen Token bereits uralt beim Client an & #39;s-Abrechnung Und natürlich gibt sich der Sekunden-gegen-Millisekunden-Vergleichsfehler - der von bit Toolz.dev - in dem Moment an, in dem Sie ein vollkommen gültiges Bild sehen exp Auf einem Token ist Ihr Kunde abgelaufen.

Auditing, was Ihr Identitätsanbieter in Token einsetzt

Die meisten Teams haben die Token nie wirklich gelesen, ihre IdP-Minzen, und es & #39; lohnt sich. Dekodieren Sie eins und Sie können E-Mail-Adressen, vollständige Namen, Bild-URLs, Mieterkennungen finden - PII, die in jeder einzelnen API-Anfrage mitfahren, im lokalen Speicher gespeichert und von allem lesbar sind, was das Token in die Hände bekommt. Hier's meine meinungsvolle Haltung und I' Ich werde es mit jedem diskutieren: don' setze Benutzer-E-Mails nicht in JWT-Nutzlasten ein. Die 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 autorisierung sich falsch verhält, ist die Antwort in den Ansprüchen Benutzer schwört, dass sie' ein admin sind, aber 403 s bekommt? dekodieren ihr Token Wenn role verkündet user‘das Token wurde vor der Promotion geprägt und sie müssen sich neu anmelden - eine klassische Folge von staatenlosen Token, die abgestandene Schnappschüsse tragen Wenn die Rolle vorhanden ist, der Zugriff aber immer noch fehlschlägt, überprüfen Sie den genauen Namen und die Form des Anspruchs: 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" Versagt lautlos und wütend Zwei entschlüsselte Token nebeneinander - einer funktioniert, einer nicht - legen es normalerweise in weniger als einer Minute ab.

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 Widerrufsverfolgung, und so nah wie möglich an nichts anderem Wenn Ihr Aktualisierungs-Token Rollen und Profildaten trägt, wird etwas' aus - it' s immer nur einem Endpunkt präsentiert und sollte' t den Zugriffstoken duplizieren's-Job. Dieser Side-by-Side-Check fängt auch die peinliche Fehlerklasse ab, bei der beide Token versehentlich dieselbe TTL erhalten, die Ihr "15-Minuten-Zugriffsfenster & quot; in Sicherheitstheater verwandelt Fragen Sie mich, woher ich weiß, dass ich das überprüfen kann.

JWT vs. undurchsichtige Sitzungs-Token: Ein ehrlicher Vergleich

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 der 7-Tage-Aktualisierungstoken ist das Ding, das ich serverseitig töten kann. Dieser Hybrid ist das ehrliche Muster: kurzlebige zustandslose JWTs für eine billige Verifizierung, ein zustandsfähiger Kontrollpunkt für die Kontrolle Wenn Sie & #39; einen Monolithen mit einer Datenbank ausführen, sind einfache Sitzungen einfacher, kleiner und sofort widerrufbar - die JWT's Superkraft der verteilten Verifizierung löst ein Problem, das Sie nicht haben & #39; nicht.

Während wir're vergleicht - HS256 vs. RS256 auf einen Blick:

Häufig gestellte Fragen

Ist es sicher, ein JWT in einen Online-Decoder einzufügen?

Nur wenn der Decoder clientseitig ausgeführt wird Ein echtes Token ist ein Live-Anmeldeinformationen - das Senden an jemanden' s Server pflanzt einen funktionierenden Schlüssel in seine Protokolle Der Toolz.dev JWT Decoder übernimmt die gesamte Dekodierung in Ihrem Browser und überträgt nichts; Sie können dies selbst bestätigen, indem Sie beim Einfügen den Netzwerk-Tab ansehen. Für Decoder können Sie ' t nur abgelaufene Token überprüfen, verwenden oder testen.

Können Sie ein JWT ohne das Geheimnis entschlüsseln?

Ja - das & #39; s der Punkt, den die Leute am meisten übersehen Der Header und die Nutzlast sind base64url-kodiertes JSON, und die Kodierung ist keine Verschlüsselung Jeder kann jeden Anspruch ohne jeden Schlüssel lesen Das Geheimnis (oder der private Schlüssel) wird nur benötigt, um die Signatur zu erstellen oder zu überprüfen. Die Dekodierung erfordert nichts; Vertrauen erfordert eine Ü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 Wirklich bestanden hat - entschlüsseln und das Datum überprüfen Nächster Verdächtiger: ein abgeschnittenes Token aus einem schlampigen Copy-Paste, 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, nicht verschlüsselt. Die Signatur erkennt Manipulationen, verbirgt aber nichts; die Nutzlast ist für jedermann lesbar Eine verschlüsselte Variante (JWE) existiert, ist aber in der typischen Webauth selten. Praktische Regel: Behandeln Sie jede JWT-Nutzlast als öffentlich und geben Sie niemals Passwörter, API-Schlüssel oder sensible Daten in eine.

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 - und Token produziert, die entweder sofort abgelaufen aussehen oder Verfallsdaten um das Jahr 56.000 tragen Wenn ein dekodierter Zeitstempel ein fünfstelliges Jahr anzeigt, dann ist das & #39; dein 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, richtig für einen einzelnen Dienst, der seine eigenen Token sowohl ausgibt als auch überprüft. RS256 signiert mit einem privaten Schlüssel und verifiziert mit einem öffentlichen, so dass viele Dienste verifizieren können, ohne fälschen zu können. Faustregel: monolith, HS256; Microservices oder Identitätsanbieter Dritter, RS256.

Abschluss

Ich habe das gebaut JWT-Decoder Weil ich es beim Erstellen von Toolz.dev selbst immer wieder brauchte - die gleichen 15-Minuten-Zugriffstoken und 7-Tage-Aktualisierungstoken I' haben sich in diesem Handbuch zerlegt. Es dekodiert sofort, übersetzt die Zeitstempel, die 90% der Verwirrung verursachen, und sendet Ihr Token nie irgendwo. Dieser letzte Teil ist & #39; t ein Feature-Checkbox; für ein Tool, das Live-Anmeldeinformationen verarbeitet, it& #39;s 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.