JWT-verifierare
Kontrollera om en JSON Web Token är äkta och fortfarande giltig. Klistra in tokenen tillsammans med dess HMAC-hemlighet, en publik PEM-nyckel, ett certifikat, en JWK eller en hel JWKS. Verifieraren kontrollerar signaturen med jose-biblioteket, jämför exp och nbf med den aktuella tiden och en eventuell klocktolerans och ger ett tydligt besked bredvid den avkodade headern och anspråken. Tokenar med alg none avvisas.
Vanliga frågor
Vad kontrollerar verifieraren?
Den kontrollerar signaturen mot nyckeln du anger och jämför sedan anspråken exp och nbf med den aktuella tiden. Beskedet är giltigt endast om signaturen stämmer och ingen av tidskontrollerna misslyckas. Anspråk som iss, aud och sub visas i payloaden, men jämförs inte med förväntade värden.
Vilka nycklar kan jag klistra in?
För HS256, HS384 och HS512 klistrar du in den delade hemligheten som text eller som en oct-JWK. För RSA-, EC- och EdDSA-token klistrar du in en offentlig PEM-nyckel (SPKI eller PKCS #1), ett X.509-certifikat, en offentlig eller privat JWK, en JWKS med upp till 50 nycklar eller en privat PEM-nyckel, där endast den offentliga delen används.
Hur väljs rätt nyckel från en JWKS?
Om tokenhuvudet innehåller en kid används nyckeln med samma kid i mängden, och ett felmeddelande anger kid-värdet om ingen matchar. Utan kid måste mängden innehålla exakt en nyckel. Detta motsvarar hur de flesta servrar väljer nycklar från ett jwks_uri-dokument.
Vad gör algoritmalternativet?
Med Use the token's alg hämtas algoritmen från tokenhuvudet, men nyckeln måste fortfarande passa den, så en offentlig RSA-nyckel kan aldrig användas som en HMAC-hemlighet. Välj en specifik algoritm om du också vill kräva att token använder den, vilket är så en server bör låsa sin förväntade algoritm. En token med en annan alg avvisas då och båda namnen visas.
Varför avvisas en token med alg none?
En token med alg none saknar signatur, så det finns inget att verifiera och vem som helst kan ha skrivit den. Att godta sådana token är en välkänd sårbarhet i JWT-bibliotek. Verifieraren rapporterar det som ett fel i stället för ett giltigt resultat.
Hur fungerar exp, nbf och klocktoleransen?
En token räknas som utgången när exp är lika med eller tidigare än den aktuella tiden, och som ännu inte giltig när nbf är senare än den aktuella tiden. Klocktoleransen, från 0 till 3600 sekunder, utökar båda kontrollerna för att tillåta tidsskillnader mellan servrar. Anspråk som finns men inte är numeriska gör token ogiltig.
Vad innebär en ogiltig signatur?
Token signerades inte med nyckeln du angav, eller så ändrades dess huvud eller nyttolast efter signeringen. Kontrollera att du klistrade in matchande offentlig nyckel eller hemlighet, med exakt samma tecken, och att hela token kopierades. Det avkodade huvudet och nyttolasten visas fortfarande så att du kan jämföra dem.
Vilka algoritmer stöds?
HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 och EdDSA med Ed25519-nycklar. RSA-nycklar måste ha minst 2048 bitar. Krypterade token (JWE) dekrypteras inte.
Sparas token eller nyckeln?
Nej. Token och nyckeln används bara för den här verifieringen i minnet och loggas eller sparas aldrig. En offentlig nyckel är säker att dela, men hantera HMAC-hemligheter varsamt och byt ut alla hemligheter som du misstänker har läckt.
Hur stora kan token och nyckeln vara?
Token får vara upp till 65,536 tecken och nyckelfältet upp till 262,144 tecken, vilket räcker för stora JWKS-dokument. Token måste ha tre base64url-delar åtskilda av punkter, ett JSON-huvud med en alg-medlem och ett JSON-objekt som nyttolast.