# Verificator JWT Verificați dacă un Web Token JSON este autentic și încă valabil. Lipiți tokenul împreună cu secretul HMAC, o cheie publică PEM, un certificat, un JWK sau un JWKS complet, iar verificatorul verifică semnătura cu biblioteca jose, compară exp și nbf cu ora curentă și cu o toleranță opțională a ceasului și afișează un verdict clar lângă antetul și afirmațiile decodificate. Tokenurile cu alg none sunt refuzate. ## Întrebări frecvente ### Ce verifică instrumentul? Verifică semnătura folosind cheia furnizată, apoi compară afirmațiile exp și nbf cu ora curentă. Verdictul este valid numai dacă semnătura corespunde și niciuna dintre verificările temporale nu eșuează. Afirmații precum iss, aud sau sub sunt afișate în payload, dar nu sunt comparate cu valori așteptate. ### Ce chei pot lipi? Pentru HS256, HS384 și HS512, introduceți secretul partajat ca text sau ca JWK oct. Pentru tokenurile RSA, EC și EdDSA, introduceți o cheie publică PEM (SPKI sau PKCS #1), un certificat X.509, un JWK public sau privat, un JWKS cu până la 50 de chei ori o cheie PEM privată, din care se folosește doar partea publică. ### Cum se alege cheia potrivită dintr-un JWKS? Dacă antetul tokenului conține un kid, se folosește cheia din set cu același kid, iar dacă nu există nicio potrivire, o eroare indică kid-ul. Fără kid, setul trebuie să conțină exact o cheie. Acest comportament reflectă modul în care majoritatea serverelor selectează cheile dintr-un document jwks_uri. ### Ce face opțiunea de algoritm? Cu Use the token's alg, algoritmul este preluat din antetul tokenului, dar cheia trebuie în continuare să fie compatibilă cu acesta, așadar o cheie publică RSA nu poate fi folosită niciodată ca secret HMAC. Alegeți un algoritm specific pentru a impune și ca tokenul să îl folosească, așa cum ar trebui un server să fixeze algoritmul așteptat. Un token cu alt alg este apoi respins, iar ambele nume sunt afișate. ### De ce este refuzat un token cu alg none? Un token cu alg none nu conține nicio semnătură, așadar nu există nimic de verificat și oricine l-ar fi putut scrie. Acceptarea acestor tokenuri este o vulnerabilitate bine cunoscută în bibliotecile JWT. Verificatorul raportează o eroare, nu un rezultat valid. ### Cum funcționează exp, nbf și toleranța ceasului? Un token este considerat expirat când exp este la momentul curent sau înaintea acestuia și încă nevalid când nbf este ulterior momentului curent. Toleranța ceasului, de la 0 la 3600 secunde, extinde ambele verificări pentru a permite diferențe între ceasurile serverelor. Revendicările prezente, dar nenumerice, invalidează tokenul. ### Ce înseamnă o semnătură invalidă? Tokenul nu a fost semnat cu cheia furnizată sau antetul ori conținutul său a fost modificat după semnare. Verificați dacă ați introdus cheia publică sau secretul corespunzător, cu toate caracterele exacte, și dacă tokenul a fost copiat integral. Antetul și conținutul decodificate sunt afișate în continuare, pentru a le putea compara. ### Ce algoritmi sunt acceptați? HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 și EdDSA cu chei Ed25519. Cheile RSA trebuie să aibă cel puțin 2048 de biți. Tokenurile criptate (JWE) nu sunt decriptate. ### Tokenul sau cheia sunt stocate? Nu. Tokenul și cheia sunt folosite doar în memorie pentru această verificare și nu sunt niciodată înregistrate sau salvate. O cheie publică poate fi distribuită în siguranță, dar tratați cu grijă secretele HMAC și schimbați orice secret despre care suspectați că a fost compromis. ### Ce dimensiune pot avea tokenul și cheia? Tokenurile pot avea până la 65,536 de caractere, iar câmpul cheii până la 262,144 de caractere, suficient pentru documente JWKS mari. Tokenul trebuie să aibă trei părți base64url separate prin puncte, un antet JSON cu un membru alg și un obiect JSON drept conținut. Reclama dvs. aici? [Trimiteți-ne un e-mail](mailto:hi@dennn.is?subject=Publicitate%20pe%20OneClick%20Pro) [Reclamă Suita de pluginuri pregătită pentru agenți pentru WordPress.](https://sleekwp.com/?ref=oneclickpro)