Ingen upload, 100% lokalt, ingen konto

Sådan gør du

Sådan afkoder du en JWT uden at lække den

En JSON Web Token bærer rigtige data: hvilken bruger den blev udstedt til, hvilke tilladelser den giver, hvornår den udløber. At indsætte en i en tilfældig afkoder på nettet betyder, at du udleverer de data, og ofte en stadig gyldig session, til en server du ikke kontrollerer. Afkoderen nedenfor kører helt i din browser, så du kan læse hvad der er inde i en token, tjekke om den er udløbet og bekræfte en HMAC-signatur når du kender hemmeligheden, alt sammen uden at en eneste netværksanmodning forlader din fane.

Skrevet af Bastien Sulyan · Udgivet den

Trin for trin

  1. Åbn JWT-afkoderen og indsæt din token i indtastningsfeltet. En JWT består af tre Base64Url-dele samlet med punktummer: header, payload og signatur. Du kan indsætte den med præfikset Bearer eller uden; værktøjet læser strukturen uanset hvad og siger straks til, hvis formatet er forkert.
  2. Læs den afkodede header og payload. Headeren viser signeringsalgoritmen (for eksempel HS256 eller RS256) og nøgle-id'et når det findes. Payloaden viser dens claims: hvem token er til (sub), hvem der udstedte den (iss), og tidsstemplerne. Værktøjet omdanner de numeriske felter iat, nbf og exp til læsbare datoer og markerer om token stadig er gyldig eller allerede er udløbet.
    En afkodet JWT, der viser headerens algoritme og payloadens claims med læsbare datoer for udstedelse og udløb
  3. Hvis token bruger HS256, og du har den delte hemmelighed, så indsæt hemmeligheden i verifikationsfeltet og klik Verificer. Værktøjet genberegner HMAC'en over headeren og payloaden og sammenligner den med signaturen, så du får at vide om token er ægte eller er blevet manipuleret. For RS256- eller ES256-tokens sker signeringen med en privat nøgle, du ikke har, så værktøjet inspicerer dens claims men hævder ikke at verificere signaturen.
    HMAC-verifikationsfeltet udfyldt med den delte hemmelighed og et mærke for gyldig signatur for en HS256-token

Hvorfor du aldrig bør indsætte en token på en tilfældig side

En JWT er ikke krypteret. Headeren og payloaden er kun Base64Url-kodet, hvilket betyder at enhver, der modtager token, kan læse hvert claim i den: e-mail, bruger-id, roller, interne flag. Hvis token er en adgangstoken, der ikke er udløbet, kan den, der har den, afspille den igen og optræde som dig, indtil den udløber. Når du indsætter en levende token i en afkoder på nettet, sender du alt dette til den servers logfiler. At afkode token på din egen maskine, uden upload, er den eneste måde at inspicere den på uden at udvide kredsen, der kan se den. Du kan bekræfte, at der ikke er nogen trafik, ved at åbne netværkspanelet mens du afkoder.

Hvad signaturen kan og ikke kan fortælle dig

Signaturen er det, der forhindrer nogen i at ændre dens claims og slippe af sted med det. For en HS256-token signerer og verificerer den samme hemmelighed, så hvis du kender hemmeligheden, kan du fuldt ud bekræfte, at token er autentisk lige her. For RS256- og ES256-tokens signerer en privat nøgle token, og kun den tilsvarende offentlige nøgle verificerer den; den private nøgle forlader aldrig udstederen, så et værktøj på klientsiden kan læse dens claims men kan ikke ærligt bevise signaturen uden den offentlige nøgle. Behandl den afkodede payload som en påstand fra udstederen, ikke som bevis, indtil signaturen er tjekket af den, der ejer verifikationsnøglen. For at hashe eller sammenligne hemmeligheder separat kører hashgeneratoren på denne side også lokalt.

JWT-struktur og hvad hver del afslører

En JWT er tre Base64url-kodede segmenter adskilt af punktummer: header, payload og signatur. Headeren angiver tokentypen ("JWT") og algoritmen: HS256 (HMAC-SHA-256, en delt hemmelighed) eller RS256 (RSA-SHA-256, et offentligt/privat nøglepar) er de mest almindelige. Payload'en bærer claims som `sub` (emne, normalt et bruger-ID), `iat` (udstedt Unix-tidsstempel), `exp` (udløbs Unix-tidsstempel), `aud` (tiltænkt målgruppe) og brugerdefinerede applikationsclaims som roller eller scopes. Base64url er ikke kryptering: det er en URL-sikker variant af Base64, der erstatter `+` med `-` og `/` med `_`, og udelader polstring. Enhver, der har den rå token-streng, kan afkode headeren og payload'en uden signeringsnøglen. Kun signatursegmentet kræver nøglen til verifikation. Det er derfor, at indsætte et live produktions-token i en ekstern online-dekoder er en sikkerhedsrisiko: hvis tokenets `exp` stadig er i fremtiden, og tjenesten logger inputtet, kan den session, det repræsenterer, kompromitteres.

Værktøjerne brugt i denne guide

Ofte stillede spørgsmål

Bliver min token sendt til en server, når jeg afkoder den?

Nej. Afkoderen opdeler token, Base64Url-afkoder headeren og payloaden og viser dem i hukommelsen. Det valgfrie HMAC-tjek bruger din browsers indbyggede Web Crypto API. Intet rejser over netværket, hvilket betyder noget, fordi en JWT ofte indeholder personoplysninger og en session, der stadig er aktiv. Åbn din browsers netværkspanel mens du afkoder, så vil du se, at ingen anmodning går ud.

Kan dette værktøj verificere en RS256- eller ES256-signatur?

Ikke fuldt ud, og det vil ikke lade som om. HS256 bruger én delt hemmelighed til både signering og verifikation, så at indsætte den hemmelighed lader værktøjet bekræfte signaturen i din browser. RS256 og ES256 bruger en privat nøgle til at signere og en separat offentlig nøgle til at verificere; værktøjet læser og validerer dens claims og udløb men afstår fra at hævde en signatur, det ikke kan tjekke. For de tokens, verificer på den tjeneste, der har den offentlige nøgle.

Kilder