JWT-verifikator
Kontrollér, om et JSON Web Token er ægte og stadig gyldigt. Indsæt tokenet sammen med dets HMAC-hemmelighed, en offentlig PEM-nøgle, et certifikat, en JWK eller en hel JWKS. Verifikatoren kontrollerer signaturen med jose-biblioteket, sammenligner exp og nbf med det aktuelle tidspunkt og en eventuel klokketolerance og viser en tydelig afgørelse ved siden af den afkodede header og claims. Tokens med alg none afvises.
Ofte stillede spørgsmål
Hvad kontrollerer verifikatoren?
Den kontrollerer signaturen mod den nøgle, du angiver, og sammenligner derefter exp-claimen og nbf-claimen med det aktuelle tidspunkt. Afgørelsen er kun gyldig, når signaturen stemmer, og ingen af tidskontrollerne fejler. Claims som iss, aud eller sub vises i payload, men sammenlignes ikke med forventede værdier.
Hvilke nøgler kan jeg indsætte?
For HS256, HS384 og HS512 indsætter du den delte hemmelighed som tekst eller som en oct JWK. For RSA-, EC- og EdDSA-tokens indsætter du en offentlig PEM-nøgle (SPKI eller PKCS #1), et X.509 certifikat, en offentlig eller privat JWK, en JWKS med op til 50 nøgler eller en privat PEM-nøgle, hvor kun den offentlige del bruges.
Hvordan vælges den rigtige nøgle fra en JWKS?
Hvis tokenets header har et kid, bruges nøglen med samme kid i sættet, og en fejl angiver kid-værdien, hvis ingen nøgle matcher. Uden et kid skal sættet indeholde præcis én nøgle. Det afspejler den måde, de fleste servere vælger nøgler fra et jwks_uri-dokument på.
Hvad gør algoritmeindstillingen?
Med Use the token's alg hentes algoritmen fra tokenets header, men nøglen skal stadig passe til den, så en offentlig RSA-nøgle kan aldrig bruges som en HMAC-hemmelighed. Vælg en bestemt algoritme for også at kræve, at tokenet bruger den; sådan bør en server fastlåse den forventede algoritme. Et token med en anden alg afvises derefter, og begge navne vises.
Hvorfor afvises et token med alg none?
Et token med alg none har ingen signatur, så der er intet at verificere, og hvem som helst kunne have skrevet det. Accept af sådanne tokens er en velkendt sårbarhed i JWT-biblioteker. Verifikatoren rapporterer det som en fejl i stedet for et gyldigt resultat.
Hvordan fungerer exp, nbf og klokketolerancen?
Et token regnes som udløbet, når exp er lig med eller tidligere end det aktuelle tidspunkt, og som endnu ikke gyldigt, når nbf ligger efter det aktuelle tidspunkt. Klokketolerancen på 0 til 3600 sekunder udvider begge kontroller, så der tages højde for tidsafvigelser mellem servere. Tilføjelser, der er til stede, men ikke er numeriske, gør tokenet ugyldigt.
Hvad betyder en ugyldig signatur?
Tokenet blev ikke signeret med den nøgle, du angav, eller dets header eller payload blev ændret efter signeringen. Kontrollér, at du indsatte den tilsvarende offentlige nøgle eller hemmelighed med præcis de rigtige tegn, og at hele tokenet blev kopieret. Den afkodede header og payload vises stadig, så du kan sammenligne dem.
Hvilke algoritmer understøttes?
HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 og EdDSA med Ed25519-nøgler. RSA-nøgler skal have mindst 2048 bit. Krypterede tokens (JWE) dekrypteres ikke.
Gemmes tokenet eller nøglen?
Nej. Tokenet og nøglen bruges kun til denne verifikation i hukommelsen og logges eller gemmes aldrig. En offentlig nøgle kan deles uden risiko, men behandl HMAC-hemmeligheder forsigtigt, og udskift enhver hemmelighed, du har mistanke om er blevet lækket.
Hvor store må tokenet og nøglen være?
Tokens må være op til 65,536 tegn, og nøglefeltet op til 262,144 tegn, hvilket giver plads til store JWKS-dokumenter. Tokenet skal have tre base64url-dele adskilt af punktummer, en JSON-header med et alg-medlem og et JSON-objekt som payload.