Decodor JWT

Lipește orice token JWT și vezi instantaneu header-ul și payload-ul decodate ca JSON formatat.\n\nDecoderul nostru:\n\n- identifică algoritmul de semnare\n- afișează toate revendicările standard și personalizate\n- convertește timestamp-urile Unix în date lizibile prin calculare ore automată\n\nAfișajul codat pe culori facilitează distingerea celor trei părți ale JWT.

Depanează problemele JWT verificând timpii de expirare, timestamp-urile de emitere și valorile revendicărilor.\n\nInstrumentul nostru arată dacă tokenurile sunt expirate, determinând un numar de zile intre doua date sau timpul rămas, și evidențiază potențialele probleme.\n\nEsențial pentru:\n\n- dezvoltarea de API-uri\n- depanarea autentificării\n- auditul de securitate

Un JSON Web Token (JWT) este o modalitate compactă și sigură pentru URL-uri de a reprezenta revendicări transferate între două părți, definită de RFC 7519 de la IETF.\n\nUn JWT are trei părți separate prin puncte, fiecare fiind codificată Base64URL conform RFC 4648:\n\n- un header care declară algoritmul de semnare și tipul de token folosind JSON (RFC 8259)\n- un payload care transportă revendicări — afirmații despre o entitate, cum ar fi un utilizator, plus metadate precum expirarea\n- o semnătură care leagă header-ul și payload-ul împreună, astfel încât orice modificare neautorizată să poată fi detectată\n\nAceastă structură permite serviciilor să verifice identitatea fără o interogare a bazei de date, motiv pentru care JWT-urile sunt comune în autentificarea stateless și în fluxurile OpenID Connect.

Pentru a decoda un JWT, împarte tokenul la cele două puncte în trei segmente, apoi decodează Base64URL primele două.\n\nPrimul segment oferă JSON-ul header-ului, iar al doilea oferă JSON-ul payload-ului, ambele fiind lizibile ca text simplu conform RFC 8259.\n\nBase64URL (RFC 4648, secțiunea 5) înlocuiește „+” cu „-” și „/” cu „_” și omite completarea (padding), motiv pentru care un decoder Base64 standard poate eșua fără ajustări. Instrumentul nostru se ocupă de acest lucru automat și afișează rezultatul formatat frumos.\n\nAl treilea segment, semnătura, nu este decodat în text deoarece este o valoare criptografică brută.\n\nDupă cum notează MDN Web Docs, decodarea nu înseamnă verificare — simpla citire a unui payload nu confirmă niciodată că tokenul este autentic.

Nu — un JWT semnat standard (un JWS) este codificat, nu criptat, astfel încât oricine deține tokenul îi poate citi payload-ul.\n\nCodificarea Base64URL (RFC 4648) este reversibilă și oferă confidențialitate zero; ea face doar posibil transportul sigur al datelor binare. Semnătura descrisă în RFC 7515 (JSON Web Signature) protejează integritatea și autenticitatea, nu secretul.\n\nDacă ai nevoie ca datele să fie ascunse, folosește în schimb JWE (JSON Web Encryption, RFC 7516).\n\nAtât OWASP, cât și IETF subliniază această distincție: nu introduce niciodată parole, secrete API sau date de identificare personală în payload-ul unui JWT semnat, deoarece un decoder ca acesta dezvăluie fiecare revendicare în text simplu, fără a fi nevoie de vreo cheie.

Revendicările înregistrate JWT sunt standardizate prin RFC 7519, astfel încât diferite sisteme să le interpreteze în mod consecvent.\n\nSetul de bază include:\n\n- „iss” (emitentul)\n- „sub” (subiectul, beneficiarul tokenului)\n- „aud” (audiența, destinatarul vizat)\n- „exp” (timpul de expirare)\n- „nbf” (nu înainte de)\n- „iat” (emis la)\n- „jti” (un ID unic de token)\n\nValorile exp, nbf și iat sunt valori NumericDate — secunde scurse de la epoca Unix — pe care decoderul nostru le convertește în date ușor de citit printr-un calcul ore precis. Aplicațiile adaugă revendicări personalizate (private) pentru roluri, permisiuni (scopes) sau ID-uri de clienți (tenant IDs).\n\nConform specificației, verificatorii trebuie să respingă un token al cărui „exp” a trecut sau a cărui „aud” nu se potrivește cu audiența așteptată, prevenind utilizarea abuzivă între servicii.

Algoritmii de semnare JWT sunt definiți în RFC 7518 (JSON Web Algorithms) și identificați prin valoarea „alg” din header.\n\n- Algoritmii HMAC (HS256, HS384, HS512) folosesc o singură cheie secretă partajată atât pentru semnare, cât și pentru verificare, ceea ce este simplu, dar necesită ca fiecare verificator să dețină acea cheie secretă.\n- Algoritmii RSA (RS256, RS384, RS512) și RSASSA-PSS (PS256) folosesc o cheie privată pentru a semna și o cheie publică pentru a verifica, fiind ideali pentru sisteme distribuite și OpenID Connect.\n- Algoritmii ECDSA (ES256, ES384, ES512) oferă o securitate echivalentă cu chei și semnături mai mici.\n\nNIST publică standardele SHA-2 și ECDSA subiacente. Decoderul nostru citește câmpul „alg” pentru ca tu să poți confirma ce schemă folosește un token.

Tokenurile JWT sunt utilizate pe scară largă pentru autentificare fără stare (stateless), autorizare și schimb securizat de informații în API-urile moderne.\n\nDupă ce un utilizator se conectează, un server emite un JWT semnat pe care clientul îl returnează în antetul HTTP Authorization ca un token Bearer, conform RFC 6750. Deoarece semnătura este de sine stătătoare, serviciile de backend pot verifica tokenul fără a interoga o bază de date de sesiuni, ceea ce îmbunătățește scalabilitatea.\n\nDe asemenea, JWT-urile stau la baza tokenurilor de ID OpenID Connect și a modelelor de tokenuri de acces OAuth 2.0.\n\nDezvoltatorii folosesc decodificatoare în timpul depanării pentru a inspecta revendicările (claims), pentru a confirma valorile pentru audiență și emitent și pentru a verifica expirarea atunci când un API returnează erori 401. Așa cum descrie MDN Web Docs, acest flux bazat pe tokenuri stă la baza multor arhitecturi de tip single-sign-on și microservicii.

Utilizarea securizată a JWT se concentrează pe validarea algoritmului, verificarea semnăturii și aplicarea expirării.\n\nOWASP avertizează împotriva atacului clasic 'alg: none' și a atacurilor de confuzie a algoritmilor, în care un server păcălit să trateze o cheie publică RS256 ca pe un secret HMAC poate genera tokenuri falsificate; fixați întotdeauna algoritmul așteptat în loc să aveți încredere în antet.\n\nPractici cheie:\n\n- Utilizați durate de viață scurte pentru 'exp' împreună cu tokenuri de reîmprospătare (refresh tokens) și validați 'iss' și 'aud' la fiecare cerere.\n- Nu stocați niciodată secrete în payload, deoarece acesta este doar codificat Base64.\n- Transmiteți tokenurile exclusiv prin HTTPS și luați în considerare strategii de revocare, deoarece JWT-urile standard nu pot fi invalidate individual înainte de expirare.\n\nRespectarea acestor recomandări IETF și OWASP elimină cele mai exploatate vulnerabilități JWT.

Cele mai frecvente greșeli la lucrul cu JWT-uri includ:\n\n- Confundarea decodificării cu verificarea: citirea unui payload cu un decodificator nu dovedește nimic despre autenticitate, deoarece oricine poate crea un token nesemnat sau falsificat.\n- Încrederea oarbă în valoarea 'alg' din antet, ceea ce permite atacurile de confuzie a algoritmilor semnalate de OWASP.\n- Interpretarea greșită a expirării prin compararea valorii 'exp' în secunde (epoch) cu milisecunde, ceea ce face ca tokenurile valide să pară expirate.\n- Utilizarea unui decodificator Base64 standard în loc de Base64URL (RFC 4648), ceea ce poate corupe rezultatul din cauza alfabetului diferit și a lipsei de padding.\n- Introducerea de date sensibile în payload, ceea ce duce la scurgerea acestora, deoarece tokenul este doar codificat, nu criptat.\n\nVerificarea semnăturilor pe partea de server cu cheia și algoritmul așteptat evită aceste probleme.

Acest decodificator JWT procesează tokenurile în întregime pe partea de client, astfel încât tokenul tău nu părăsește niciodată dispozitivul și nu ajunge pe niciun server.\n\nDeoarece un JWT semnat este doar codificat Base64URL (RFC 4648), decodificarea nu necesită niciun apel de rețea — antetul și payload-ul sunt pur și simplu decodificate din forma lor inițială folosind JavaScript direct în browserul tău.\n\nPăstrarea operațiunii la nivel local este esențială pentru securitate: tokenurile conțin adesea date de sesiune active, iar introducerea lor într-un instrument de pe server le-ar putea expune în loguri sau în tranzit. OWASP recomandă minimizarea locurilor în care circulă datele de autentificare sensibile.\n\nUn decodificator exclusiv în browser permite dezvoltatorilor să inspecteze în siguranță tokenurile de producție în timpul depanării, respectând în același timp principiul expunerii minime, fără a transmite date de autorizare către terți.