Utilia

JWT-generator og -verifikator

Opret og verificér JSON Web Tokens med HS256, RS256, PS256, ES256 eller EdDSA. Rediger claims, sæt exp og iat, og tjek signaturer lokalt i din browser.

Nøgler og tokens er hemmeligheder. Alt signeres og verificeres lokalt med din browsers Web Crypto API: intet uploades.

Opret et signeret JWT

Tidsclaims:

Verificér et JWT

Sådan opretter du et signeret JWT

  1. Vælg Algoritme: HS256/384/512 (delt hemmelighed), RS256/384/512 eller PS256/384/512 (RSA), ES256/384/512 (ECDSA på P-256, P-384 eller P-521) eller EdDSA (Ed25519, hvis din browser understøtter det).
  2. Rediger Header (JSON) og Payload (JSON-claims). Feltet alg følger altid den valgte algoritme, og typ er som standard JWT.
  3. Brug knapperne til tidsclaims til at tilføje datoer: iat = nu, nbf = nu, eller vælg en forsinkelse som »om 1 time« og klik på Sæt exp. Værdierne er NumericDates: sekunder siden 1. januar 1970 UTC.
  4. Indtast Hemmelighed (HS-algoritmer, som tekst eller Base64/Base64url under Format for hemmeligheden) eller Privat nøgle (PEM eller JWK). Har du ingen nøgle endnu? Klik på Generér testnøgle.
  5. Klik på Signér token, og Kopiér derefter resultatet, eller klik på Verificér dette token for at kontrollere det med det samme.

Sådan verificerer du et JWT

  1. Indsæt tokenet under Token, der skal verificeres.
  2. Vælg Forventet algoritme. Hvis du lader den stå på »Fra tokenets header«, accepteres alt, hvad headeren siger, undtagen none. Vælger du en bestemt algoritme, afviser værktøjet ethvert token, der er signeret anderledes, som en rigtig server bør gøre.
  3. Indtast hemmeligheden eller Offentlig nøgle (PEM eller JWK): en PEM-blok af typen PUBLIC KEY, RSA PUBLIC KEY eller CERTIFICATE, en JWK eller et JWK Set (den nøgle, hvis kid svarer til headeren, bruges).
  4. Angiv eventuelt Tolerance for uret (sekunder) for at tillade små forskelle i klokkeslæt, og klik på Verificér token.

Resultatet viser, om signaturen er gyldig, og kontrollerer derefter exp (udløb) og nbf (ikke gyldigt før) mod din computers aktuelle tid. Et token med korrekt signatur, men en udløbstid i fortiden, meldes som udløbet og ikke som gyldigt.

Nøgler og formater

Til signering accepterer værktøjet PKCS#8-blokke af typen PRIVATE KEY, PKCS#1-blokke af typen RSA PRIVATE KEY, SEC1-blokke af typen EC PRIVATE KEY (konverteres internt til PKCS#8) og private JWK’er. Nøgler beskyttet med adgangskode skal først eksporteres uden adgangskode. Generér testnøgle opretter en tilfældig hemmelighed på hashværdiens størrelse til HS-algoritmer, et RSA-nøglepar på 2048 bit til RS og PS, den tilsvarende kurve til ES eller et Ed25519-par. Du får nøglerne som PEM og JWK, og de udfyldes begge steder, så en rundtur virker med det samme.

Signaturerne følger RFC 7515 og RFC 7518: RSA-PSS bruger et salt, der er lige så langt som hashværdien, og ECDSA-signaturer er den rå sammenkædning r||s. Implementeringen gengiver HS256-eksemplet i RFC 7515, bilag A.1.

Sikkerhedsnoter

  • Alt kører i din browser med Web Crypto API. Hverken tokens eller nøgler sendes nogen steder hen, men brug alligevel hellere testnøgler end produktionshemmeligheder.
  • alg: none signeres aldrig og accepteres aldrig.
  • HMAC-hemmeligheder bør mindst være lige så lange som hashværdien (32 byte til HS256). En kortere hemmelighed udløser en advarsel.
  • En signatur beviser integritet og afsender, ikke at claims er passende: servere skal også kontrollere iss, aud og scopes.

Ofte stillede spørgsmål

Hvad er forskellen på HS256 og RS256?

HS256 bruger én delt hemmelighed både til at signere og til at verificere, så enhver, der kan verificere, også kunne forfalske tokens. RS256 (og PS256, ES256, EdDSA) signerer med en privat nøgle og verificerer med en offentlig nøgle, som sagtens kan offentliggøres.

Hvorfor viser en gyldig signatur stadig en fejl?

Fordi tokenet er uden for sin gyldighedsperiode: exp ligger i fortiden, eller nbf ligger i fremtiden. Kontrollen af signaturen og tidskontrollen meldes hver for sig.

Hvorfor afvises alg »none«?

Et usigneret token kan oprettes af alle. At acceptere det var en klassisk sårbarhed i JWT-biblioteker, så dette værktøj afviser det både ved signering og ved verificering.

Kan jeg bruge min egen RSA- eller EC-nøgle?

Ja. Indsæt den private nøgle som PEM eller JWK for at signere og den offentlige nøgle for at verificere. Værktøjet kontrollerer, at nøgletype og kurve passer til den valgte algoritme.

Hvorfor er EdDSA deaktiveret?

Din browser understøtter endnu ikke Ed25519 i Web Crypto. Nyere versioner af Chrome, Edge, Firefox og Safari gør.