JWT-dekoder

Oppbyggingen av en JSON Web Token

En JSON Web Token (JWT) er en kompakt og uavhengig metode for sikker overføring av informasjon mellom parter som et JSON-objekt. Tokenet er bygget opp av tre deler som er separert med punktum. Disse tre delene er:

1. Header: Inneholder metadata om tokenet, vanligvis hvilken algoritme som er brukt til å signere det, og typen token.
2. Payload: Inneholder selve dataene eller påstandene (claims) som overføres, for eksempel brukerinformasjon og tidsstempler.
3. Signatur: Brukes til å verifisere at avsenderen er den som oppgis, og for å sikre at meldingen ikke har blitt endret underveis.

Hver av de tre delene er kodet med Base64URL-koding før de settes sammen med punktum til en enkelt streng.

Base64URL-koding og JSON-formatet

Base64URL-koding er en variant av Base64 som er tilpasset for bruk i URL-er og filnavn. Den erstatter tegnene + og / med henholdsvis - og _, og utelater fylltegn som =. Dette gjør at tokenet trygt kan sendes som en del av en URL-parameter eller i HTTP-headere uten behov for URL-koding.

Selve innholdet i både headeren og payloaden er strukturert som JSON (JavaScript Object Notation) før det kodes. JSON gir en klar nøkkel-verdi-struktur som gjør det enkelt å lese og organisere dataene. Hvis dataene som dekodes ikke følger denne syntaksen, vil verktøyet gi feilmeldinger som "Headeren er ikke gyldig JSON" eller "Payloaden er ikke gyldig JSON".

Headeren og dens metadata

Header-delen av en JWT spesifiserer hvordan tokenet skal behandles. Den inneholder vanligvis to nøkkelopplysninger:

• Algoritme (alg): Angir hvilken kryptografisk algoritme som er brukt til å signere tokenet, for eksempel HS256 (HMAC med SHA-256) eller RS256 (RSA med SHA-256).
• Type (typ): Angir typen token, som i de fleste tilfeller er "JWT".

Når du limer inn et token i verktøyet, dekodes denne informasjonen og vises under merkelappene "Algoritme" og "Type".

Payloaden og tidsbaserte påstander

Payloaden inneholder påstandene (claims). Dette er utsagn om en enhet (for eksempel en bruker) og ytterligere metadata. Det finnes tre typer påstander: registrerte, offentlige og private påstander. De registrerte påstandene er forhåndsdefinerte nøkler som anbefales for å sikre interoperabilitet:

• iat (Issued At): Tidspunktet da tokenet ble utstedt. Dette vises i verktøyet som "Utstedt kl.".
• exp (Expiration Time): Tidspunktet da tokenet utløper og ikke lenger skal godtas. Dette vises i verktøyet som "Utløper".

Verktøyet analyserer disse tidsstemplene for å bestemme tokenets gyldighetsstatus. Basert på verdien i exp-feltet vil statusen vises som et av følgende alternativer:

• "Gyldig"
• "Utløpt"
• "Ikke gyldig ennå"
• "Ingen utløpsdato" (hvis tokenet mangler exp-påstanden)

Forskjellen mellom dekoding og verifisering

Det er en kritisk forskjell mellom å dekode en JWT og å verifisere den:

• Dekoding: Dette er kun en reversering av Base64URL-kodingen for å gjøre innholdet i headeren og payloaden lesbart. Alle som har tilgang til tokenet kan dekode det, ettersom Base64URL ikke er kryptering.
• Verifisering: Dette innebærer å kontrollere signaturen til tokenet for å bekrefte at innholdet ikke har blitt manipulert. For å gjøre dette kreves det en hemmelig nøkkel (for symmetriske algoritmer som HS256) eller en offentlig nøkkel (for asymmetriske algoritmer som RS256).

Dette verktøyet utfører kun dekoding. Det verifiserer ikke signaturen, og ber aldri om signeringens hemmelige eller offentlige nøkkel. En merknad i grensesnittet påminner om dette: "Dette sjekker kun exp-påstanden — det verifiserer ikke signaturen, utstederen eller mottakeren.". Å bruke et token uten å verifisere signaturen i et produksjonsmiljø utgjør en alvorlig sikkerhetsrisiko, ettersom hvem som helst kan ha endret innholdet i payloaden.

Feilhåndtering og valideringsregler

Når du limer inn tekst i feltet "Lim inn din JWT", utfører verktøyet flere kontroller for å sikre at inndataene er strukturelt korrekte:

• Formatkontroll: Hvis inndataene ikke inneholder nøyaktig tre deler separert med punktum, vises feilmeldingen "Ikke en gyldig JWT – forventet tre deler separert med punktum".
• Lengdebegrensning: Hvis inndataene overskrider en rimelig lengde for et reelt token, vil verktøyet stoppe behandlingen og vise "Dette er for langt til å være en ekte JWT".
• Base64URL-validering: Hvis headeren eller payloaden inneholder tegn som ikke er gyldig Base64URL, vil verktøyet vise henholdsvis "Kunne ikke dekode headeren – ugyldig Base64URL" eller "Kunne ikke dekode payloaden – ugyldig Base64URL".
• JSON-validering: Hvis de dekodede strengene ikke kan tolkes som gyldig JSON, vises "Headeren er ikke gyldig JSON" eller "Payloaden er ikke gyldig JSON".

Når en ugyldig verdi tastes inn, skjules de dekodede områdene automatisk. Hvis du klikker på "Tøm", nullstilles verktøyet til tilstanden "Klar. Lim inn en JWT for å dekode den.", og fokus returneres til inndatafeltet. Tegntelleren "Tegn" viser til enhver tid lengden på den innsendte strengen.

Personvern og lokal databehandling

Sikkerhet og personvern er ivaretatt ved at all databehandling skjer lokalt. Tokenet ditt dekodes i nettleseren din, og ingenting lastes opp til BroBroGo. Dette betyr at sensitive data i payloaden ikke eksponeres over nettverket under dekodingsprosessen.

Ofte stilte spørsmål (FAQ)

Er det trygt å lime inn min JWT her?

Ja. Dekodingen skjer utelukkende i nettleseren din – tokenet ditt sendes aldri til BroBroGo.

Verifiserer dette signaturen?

Nei. Den dekoder bare headeren og payloaden slik at du kan lese dem. Verifisering av en signatur krever en hemmelig nøkkel eller offentlig nøkkel, noe dette verktøyet aldri ber om.

Hvordan vet jeg om tokenet mitt har utløpt?

Dekoderen leser exp-feltet og viser et statusmerke – gyldig, utløpt, ikke gyldig ennå, eller ingen utløpsdato – ved siden av det dekodede tokenet.

Hvorfor får jeg feilmeldingen om at det ikke er en gyldig JWT?

Dette skjer hvis teksten du limte inn mangler punktum-separatører. En gyldig JWT må bestå av nøyaktig tre deler separert med punktum (header.payload.signatur).