JSON Web Tokens og deres opbygning
Et JSON Web Token (JWT) er en kompakt og selvstændig metode til sikker overførsel af informationer mellem parter som et JSON-objekt. En standard JWT består af tre dele, som er adskilt af punktummer:
- Header: Indeholder metadata om tokenet, herunder den anvendte kryptografiske algoritme og typen af token.
- Payload: Indeholder de faktiske data, også kaldet claims (påstande), om en enhed (typisk brugeren) samt yderligere metadata.
- Signature: Bruges til at verificere, at afsenderen af JWT-en er den, som den udgiver sig for at være, og for at sikre, at budskabet ikke er blevet ændret undervejs.
Hver af disse tre dele er kodet med Base64URL-kodning, hvilket gør det muligt at overføre tokenet sikkert i HTTP-headere og URL-parametre.
Base64URL-kodning og JSON-formatering
Base64URL er en variant af Base64-kodning, der er designet til at være sikker at bruge i URL-adresser. Den erstatter tegnene + og / med henholdsvis - og _, og udelader eventuel polstring med lighedstegn (=).
Både headeren og payloaden i en JWT skal, når de er afkodet fra Base64URL, repræsentere gyldig JSON-formatering. Hvis dataene ikke er formateret korrekt som JSON, eller hvis Base64URL-kodningen er beskadiget, kan tokenet ikke afkodes korrekt.
Headerens og payloadens claims
Headeren indeholder typisk tekniske oplysninger om tokenet. De mest almindelige felter i headeren er:
alg: Angiver den kryptografiske algoritme, der er brugt til at signere tokenet (f.eks. HS256 eller RS256).typ: Angiver typen af token, som i dette tilfælde er JWT.
Payloaden indeholder de overførte informationer, som opdeles i registrerede, offentlige eller private claims. Blandt de mest udbredte registrerede claims er:
iat(Issued At): Tidspunktet for, hvornår tokenet blev udstedt.exp(Expiration Time): Tidspunktet for, hvornår tokenet udløber og ikke længere må accepteres.
Afkodning versus verificering af en JWT
Der er en væsentlig sikkerhedsmæssig forskel på at afkode en JWT og at verificere den:
- Afkodning: Processen med at oversætte Base64URL-strengene for headeren og payloaden tilbage til læsbar JSON-tekst. Dette kræver ingen hemmelige nøgler og kan gøres af alle, der har adgang til tokenet.
- Verificering: Processen med at kontrollere tokenets signatur for at sikre, at indholdet ikke er blevet manipuleret. Dette kræver adgang til den oprindelige signaturnøgle (en symmetrisk hemmelig nøgle eller en offentlig asymmetrisk nøgle).
At undlade at verificere en JWT-signatur i et produktionsmiljø udgør en alvorlig sikkerhedsrisiko, da ondsindede aktører kan ændre i payloaden (f.eks. ændre brugerrettigheder) og indsende det modificerede token. Dette værktøj udfører udelukkende afkodning og verificerer ikke signaturen.
Sådan fungerer JWT-afkoderen
Værktøjet analyserer den indtastede JWT-streng og opdeler den i dens bestanddele. Processen følger en række faste regler og fejlmeddelelser baseret på inputtet:
- Klar-tilstand: Hvis inputfeltet er tomt, forbliver værktøjet i tilstanden "Klar. Indsæt en JWT for at afkode den.".
- Formatkontrol: Hvis inputtet ikke indeholder præcis tre dele adskilt af punktummer, vises fejlmeddelelsen "Ikke en gyldig JWT – forventede tre dele adskilt af punktum.".
- Længdebegrænsning: Hvis den indtastede streng er for lang til at repræsentere en reel token, vises meddelelsen "Det er for langt til at være en rigtig JWT.".
- Afkodning af header: Hvis headeren ikke kan afkodes på grund af fejl i Base64URL-strukturen, vises "Kunne ikke afkode headeren – ugyldig Base64URL.". Hvis den afkodede tekst ikke er gyldig JSON, vises "Headeren er ikke gyldig JSON.".
- Afkodning af payload: Hvis payloaden ikke kan afkodes på grund af fejl i Base64URL-strukturen, vises "Kunne ikke afkode payloaden – ugyldig Base64URL.". Hvis den afkodede tekst ikke er gyldig JSON, vises "Payloaden er ikke gyldig JSON.".
- Skjulning af data: Når der indtastes en ugyldig token, skjules de afkodede områder automatisk.
- Rydning: Når inputtet ryddes, returneres fokus til inputfeltet.
Når en token afkodes korrekt, viser værktøjet følgende outputværdier:
- Header: Den afkodede header formateret som JSON.
- Payload: Den afkodede payload formateret som JSON.
- Algoritme: Den anvendte algoritme udvundet fra headeren.
- Type: Tokenets type udvundet fra headeren.
- Udstedt den: Tidspunktet for udstedelse baseret på
iat-claimet. - Udløber: Udløbstidspunktet baseret på
exp-claimet. - Tegn: Det samlede antal tegn i den indtastede JWT.
Værktøjet viser desuden et statusmærkat for tokenets gyldighed baseret på udløbstiden:
- Gyldig: Tokenet er ikke udløbet endnu.
- Udløbet: Tokenets udløbstidspunkt er overskredet.
- Endnu ikke gyldig: Tokenet er konfigureret til at være gyldigt i fremtiden.
- Intet udløb: Tokenet indeholder ikke et
exp-claim.
Behandling af personlige data og privatliv
Din token afkodes i din browser. Intet uploades til BroBroGo. Al databehandling og oversættelse fra Base64URL til JSON foregår lokalt på din egen enhed. Dette sikrer, at følsomme oplysninger i din payload ikke eksponeres over for eksterne servere under afkodningen.
Målgrupper for værktøjet
Dette værktøj er udviklet til fagfolk, der arbejder med webudvikling og sikkerhed:
- Udviklere: Til fejlfinding af JWT-indhold under implementering af godkendelsessystemer.
- Supportteknikere: Til hurtig inspektion af tokens modtaget i forbindelse med fejlrapporter.
- Sikkerhedstestere: Til undersøgelse af claims og konfigurationer i tokens under sikkerhedsanalyser.
Ofte stillede spørgsmål (FAQ)
Er det sikkert at indsætte min JWT her?
Ja. Afkodningen sker udelukkende i din browser – din token sendes aldrig til BroBroGo.
Verificerer dette signaturen?
Nej. Den afkoder kun headeren og payloaden, så du kan læse dem. Verificering af en signatur kræver signatur-nøglen eller den offentlige nøgle, som dette værktøj aldrig beder om.
Hvordan ved jeg, om min token er udløbet?
Afkoderen læser exp-claimet og viser et statusmærkat – gyldig, udløbet, endnu ikke gyldig eller intet udløb – ved siden af den afkodede token.