Decodor JWT
Decodați antetul și revendicările JWT, primiți avertismente despre trucurile de algoritm și de antet care duc la falsificarea tokenurilor, semnați tokenuri noi și verificați semnături HS, RS, PS și ES în browser.
Instrumente înrudite
- Codor / DecodorCodificați și decodați Base64, URL-uri și entități HTML și convertiți baze numerice.
- Instrumente JSONFormatați, minificați, reparați și validați JSON cu poziții exacte ale erorilor, parcurgeți-l ca arbore și convertiți între JSON, CSV și YAML.
- Generator hashCalculați hash pentru text sau pentru un fișier cu MD5, SHA-1, SHA-2, SHA-3 sau HMAC.
Despre acest instrument
Decodorul JWT împarte un token compact în cele trei părți base64url ale sale, decodează antetul și payload-ul ca JSON UTF-8 (RFC 7519) și listează revendicările de timp - exp, nbf, iat și auth_time - cu valorile lor UTC. Antetul este citit pentru trucurile prin care ajung să fie acceptate tokenuri care nu ar trebui să fie: alg „none”, un algoritm HMAC acolo unde emitentul semnează cu RSA sau ECDSA (un atacator resemnează folosind cheia publică drept secret HMAC), jku, x5u, jwk și x5c care îndreaptă verificatorul spre o cheie aleasă de expeditor, parametri crit pe care niciun verificator de aici nu îi implementează, un kid lipsă și un exp aflat la mai mult de un an distanță. Un URL jku sau x5u este numit, niciodată descărcat. Poate verifica semnătura în pagină: HS256, HS384 și HS512 față de un secret partajat, iar RS, PS și ES în variantele 256, 384 și 512 față de o cheie publică PEM, un JWK sau un JWKS întreg, a cărui cheie este aleasă după kid-ul tokenului (RFC 7518). Aceiași algoritmi pot și semna: alegeți unul, editați antetul și payload-ul, furnizați secretul sau o cheie privată PKCS#8, iar tokenul este construit cu Web Crypto în pagină. Expirarea este comparată cu ceasul dispozitivului dumneavoastră, așa că nota „expirat” este corectă doar în măsura în care este și acel ceas; instrumentul nu descarcă un URL JWKS - setul trebuie lipit - și nu verifică iss, aud sau sub în locul dumneavoastră. Un JWE din cinci părți este refuzat, nu ghicit, pentru că un token criptat nu poate fi citit fără cheia de decriptare.
Token-ul, secretul HS și cheile publică și privată rămân în pagină: nu sunt trimise către API-ul XGM și nu sunt scrise niciodată în URL, așa că un link pe care îl distribuiți conține instrumentul și nimic din ce ați lipit. Decodarea folosește atob și TextDecoder, iar semnarea și verificarea folosesc amândouă Web Crypto - crypto.subtle.importKey pentru secretul HMAC brut, pentru PEM sau pentru JWK, apoi crypto.subtle.sign ori crypto.subtle.verify pentru HMAC, RSASSA-PKCS1-v1_5, RSA-PSS și ECDSA. Un JWKS lipit este comparat cu kid-ul token-ului aici, în pagină; nicio adresă JWKS nu este accesată. Avertismentele sunt citite la fel, din antetul și din claim-urile token-ului: un antet jku sau x5u este numit și niciodată urmat, iar secretul pe care îl scrieți este măsurat față de lungimea cerută de RFC 7518 fără a părăsi pagina. Exporturile JSON și Markdown sunt construite și descărcate în browser, nimic nu este scris în local storage, iar închiderea filei elimină tot ce ați introdus.
Cum se folosește
- Deschideți instrumentul Decodor JWT.
- Lipiți sau tastați datele pe care vreți să le inspectați.
- Citiți rezultatul, calculat în browser; datele nu sunt trimise către XGM.
- Copiați rezultatul doar după ce ați verificat că arată corect.
- Folosiți instrumentele XGM înrudite dacă aveți nevoie de o imagine de diagnostic mai largă.
Întrebări frecvente
Ce algoritmi poate verifica de fapt?
Familia HMAC HS256, HS384 și HS512 cu un secret partajat și familiile cu cheie publică din RFC 7518: RS256/384/512 ca RSASSA-PKCS1-v1_5, PS256/384/512 ca RSA-PSS cu o lungime a sării egală cu lungimea hash-ului în octeți, plus ES256, ES384 și ES512 ca ECDSA peste P-256, P-384 și P-521. Orice altceva, inclusiv EdDSA, este decodat, dar raportat ca neacceptat pentru verificare. Un token al cărui antet spune alg „none” este marcat drept critic și nu poate fi verificat, pentru că nu există nimic de verificat.
Secretul meu HS256 este corect, dar semnătura nu se potrivește. De ce?
În mod implicit, secretul este folosit ca octeți UTF-8 bruți, exact așa cum a fost tastat. Mulți emitenți stochează secretul codat base64 sau base64url, așa că adevărata cheie sunt octeții decodați, nu șirul afișabil - bifați „Secretul este codat base64url” în acest caz. Spațiile de la final sau un rând nou copiat odată cu secretul schimbă și ele octeții și, prin urmare, HMAC-ul (RFC 2104).
Instrumentul spune că tokenul a expirat, dar API-ul meu îl acceptă în continuare.
exp și nbf sunt secunde numerice comparate cu ceasul mașinii la care stați, nu cu ceasul emitentului sau cu un server de timp. Majoritatea bibliotecilor de server permit și o toleranță de câteva secunde în jurul lui exp și nbf, așa că un token care tocmai a trecut limita poate fi totuși acceptat acolo. Dacă iat este cu mai mult de cinci minute în viitor, instrumentul ridică un avertisment separat, ceea ce înseamnă de obicei că ceasul emitentului este greșit, nu tokenul.
Pot lipi un JWKS și de ce este respinsă cheia mea?
Puteți lipi un singur JWK sau un întreg obiect JWKS. Când JSON-ul conține un tablou „keys”, este folosită cheia al cărei kid se potrivește cu headerul tokenului; dacă nicio cheie nu poartă acel kid, instrumentul spune asta și numește kid-urile pe care le-a găsit, în loc să revină la prima cheie și să raporteze un rezultat în care nu puteți avea încredere. Un token fără kid este corelat doar când setul conține o singură cheie sau o singură cheie de tipul potrivit pentru algoritm; altfel vi se cere să lipiți exact cheia la care vă referiți. Nu este accesat niciun URL JWKS - setul trebuie lipit, pentru că endpointul emitentului ar refuza o cerere cross-origin din această pagină. În formă PEM este acceptată doar o cheie publică SPKI (-----BEGIN PUBLIC KEY-----); certificatele și cheile private nu sunt. Curba este preluată din header, așa că un header ES256 cu o cheie P-384 eșuează la import, nu la verificare.
Ce înseamnă avertismentele de deasupra claim-urilor?
Sunt problemele de antet și de claim care duc la falsificarea token-urilor, în ordinea gravității, cu alg „none” întotdeauna prima. Critic: alg „none” sau alg lipsă, o semnătură goală și antetele jku, x5u, jwk și x5c, care îi spun unui verificator să obțină sau să aibă încredere într-o cheie aleasă de expeditor - fixați-vă cheile și ignorați acele antete. Avertisment: un algoritm HS, pentru că unui verificator care citește algoritmul din token i se poate da un token RS256 resemnat ca HS256, cu cheia publică pe post de secret; un secret HMAC mai scurt decât hash-ul, lucru interzis de RFC 7518 §3.2; un kid lipsă la un algoritm asimetric; parametri crit, despre care RFC 7515 spune că un verificator care nu îi implementează trebuie să respingă token-ul; lipsa exp sau un exp la mai mult de un an distanță. Nu există scor - este o listă, iar ce nu se aplică nu este afișat.
Pot crea un token aici și este cheia în siguranță?
Da. Treceți la „Encode and sign”, alegeți unul dintre HS256/384/512, RS256/384/512, PS256/384/512 sau ES256/384/512, editați JSON-ul de header și de payload și furnizați secretul partajat sau o cheie privată PKCS#8 (-----BEGIN PRIVATE KEY-----) ori un JWK privat. Tokenul este construit cu crypto.subtle.sign în browserul dumneavoastră: cheia nu este niciodată încărcată, niciodată scrisă în URL și niciodată stocată. Headerul și payloadul sunt re-serializate compact înainte de semnare, pentru că un JWT poartă exact octeții care au fost semnați, așa că spațiile din editor nu pot face parte din intrarea de semnare. Nu se adaugă nimic pentru dumneavoastră - niciun iat, niciun exp - așa că tokenul conține exact revendicările pe care le-ați scris. O cheie PKCS#1 sau SEC1 (-----BEGIN RSA PRIVATE KEY-----) este refuzată, împreună cu comanda openssl care o convertește, pentru că Web Crypto importă doar PKCS#8.
Payload-ul este ascuns față de cel care deține tokenul?
Nu. Un JWT semnat este codificat base64url, nu criptat: oricine are tokenul citește revendicările exact cum o face această pagină, iar semnătura dovedește doar că revendicările nu au fost modificate. Instrumentul ridică un avertisment atunci când numele unei revendicări seamănă cu o parolă, un secret, un număr de card sau ceva similar, pentru că acele valori sunt practic în clar. Folosiți un JWE sau păstrați datele pe server, în spatele unei referințe opace, atunci când conținutul trebuie să rămână privat.