Ingen opplasting, 100% lokalt, ingen konto

Slik gjør du

Slik dekoder du en JWT uten å lekke den

En JSON Web Token bærer ekte data: hvilken bruker den ble utstedt til, hvilke tilganger den gir, når den utløper. Å lime en inn i en tilfeldig dekoder på nettet betyr å overlate de dataene, og ofte en fortsatt gyldig økt, til en server du ikke kontrollerer. Dekoderen nedenfor kjører helt i nettleseren din, så du kan lese hva som er inni en token, sjekke om den har utløpt og bekrefte en HMAC-signatur når du kjenner hemmeligheten, alt uten at en eneste nettverksforespørsel forlater fanen din.

Skrevet av Bastien Sulyan · Publisert

Steg for steg

  1. Åpne JWT-dekoderen og lim tokenet ditt inn i inntastingsfeltet. En JWT består av tre Base64Url-deler satt sammen med punktum: header, payload og signatur. Du kan lime den inn med prefikset Bearer eller uten; verktøyet leser strukturen uansett og sier umiddelbart fra hvis formatet er feil.
  2. Les den dekodede headeren og payloaden. Headeren viser signeringsalgoritmen (for eksempel HS256 eller RS256) og nøkkel-id-en når den finnes. Payloaden lister opp claimene: hvem tokenet er for (sub), hvem som utstedte det (iss), og tidsstemplene. Verktøyet gjør de numeriske feltene iat, nbf og exp om til lesbare datoer og markerer om tokenet fortsatt er gyldig eller allerede er utløpt.
    En dekodet JWT som viser headerens algoritme og payloadens claims med lesbare datoer for utstedelse og utløp
  3. Hvis tokenet bruker HS256 og du har den delte hemmeligheten, lim hemmeligheten inn i verifiseringsfeltet og klikk Verifiser. Verktøyet beregner HMAC-en på nytt over headeren og payloaden og sammenligner den med signaturen, slik at du finner ut om tokenet er ekte eller har blitt tuklet med. For RS256- eller ES256-tokens skjer signeringen med en privat nøkkel du ikke har, så verktøyet inspiserer claimene men hevder ikke at det verifiserer signaturen.
    HMAC-verifiseringsfeltet fylt ut med den delte hemmeligheten og et merke for gyldig signatur for et HS256-token

Hvorfor du aldri bør lime en token inn på en tilfeldig side

En JWT er ikke kryptert. Headeren og payloaden er bare Base64Url-kodet, noe som betyr at alle som mottar tokenet kan lese hvert claim i det: e-post, bruker-id, roller, interne flagg. Hvis tokenet er et tilgangstoken som ikke har utløpt, kan den som har det spille det av på nytt og opptre som deg helt til det utløper. Når du limer et levende token inn i en dekoder på nettet, sender du alt dette til den serverens logger. Å dekode tokenet på din egen maskin, uten opplasting, er den eneste måten å inspisere det på uten å utvide kretsen som kan se det. Du kan bekrefte at det ikke er noen trafikk ved å åpne nettverkspanelet mens du dekoder.

Hva signaturen kan og ikke kan fortelle deg

Signaturen er det som hindrer noen i å endre claimene og slippe unna med det. For et HS256-token signerer og verifiserer den samme hemmeligheten, så hvis du kjenner hemmeligheten kan du fullt ut bekrefte at tokenet er autentisk her og nå. For RS256- og ES256-tokens signerer en privat nøkkel tokenet og bare den tilhørende offentlige nøkkelen verifiserer det; den private nøkkelen forlater aldri utstederen, så et verktøy på klientsiden kan lese claimene men kan ikke ærlig bevise signaturen uten den offentlige nøkkelen. Behandle den dekodede payloaden som en påstand fra utstederen, ikke som bevis, til signaturen er sjekket av den som eier verifiseringsnøkkelen. For å hashe eller sammenligne hemmeligheter separat kjører hashgeneratoren på denne siden også lokalt.

JWT-struktur og hva hver del avslører

En JWT er tre Base64url-kodede segmenter atskilt med punktum: header, nyttelast og signatur. Headeren erklærer tokentypen ("JWT") og algoritmen: HS256 (HMAC-SHA-256, en delt hemmelighet) eller RS256 (RSA-SHA-256, et offentlig/privat nøkkelpar) er de vanligste. Nyttelasten bærer krav som `sub` (emne, vanligvis en bruker-ID), `iat` (utstedt-ved Unix-tidsstempel), `exp` (utløp Unix-tidsstempel), `aud` (tiltenkt mottaker), og egendefinerte applikasjonskrav som roller eller scopes. Base64url er ikke kryptering: det er en URL-sikker variant av Base64 som erstatter `+` med `-` og `/` med `_`, og utelater utfylling. Alle som har den rå tokenstrengen kan dekode headeren og nyttelasten uten signeringsnøkkelen. Bare signatursegmentet krever nøkkelen for å verifisere. Det er derfor det å lime inn et live produksjonstoken i en ekstern online-dekoder er en sikkerhetsrisiko: hvis tokenets `exp` fortsatt er i fremtiden og tjenesten logger inndataene, kan den sesjonen den representerer bli kompromittert.

Verktøyene brukt i denne guiden

Ofte stilte spørsmål

Blir tokenet mitt sendt til noen server når jeg dekoder det?

Nei. Dekoderen splitter tokenet, Base64Url-dekoder headeren og payloaden og viser dem i minnet. Den valgfrie HMAC-sjekken bruker nettleserens innebygde Web Crypto API. Ingenting reiser over nettverket, noe som betyr noe fordi en JWT ofte inneholder personopplysninger og en økt som fortsatt er aktiv. Åpne nettleserens nettverkspanel mens du dekoder, så ser du at ingen forespørsel går ut.

Kan dette verktøyet verifisere en RS256- eller ES256-signatur?

Ikke fullt ut, og det vil ikke late som. HS256 bruker én delt hemmelighet for både signering og verifisering, så å lime inn den hemmeligheten lar verktøyet bekrefte signaturen i nettleseren din. RS256 og ES256 bruker en privat nøkkel for å signere og en egen offentlig nøkkel for å verifisere; verktøyet leser og validerer claimene og utløpet men avstår fra å hevde en signatur det ikke kan sjekke. For de tokenene, verifiser på tjenesten som har den offentlige nøkkelen.

Kilder