JWT-dekoder
Lim inn en JWT for å dekode og inspisere header, payload og krav.
Hva er en JWT?
En JSON Web Token (JWT, uttalt «jot») er et kompakt, URL-sikkert tokenformat definert i RFC 7519. JWT-er er industristandarden for å overføre autentiserings- og autorisasjonsinformasjon mellom parter. De brukes mye i single sign-on (SSO)-systemer, OAuth 2.0-flyter og API-autentisering.
En JWT består av tre Base64URL-kodede deler atskilt med punktum: en header, en payload og en signatur. Headeren spesifiserer signeringsalgoritmen (f.eks. HS256, RS256). Payloaden inneholder påstander (claims) — nøkkel-verdi-par med informasjon som bruker-ID, tillatelser og utløpstid. Signaturen sikrer at tokenet ikke har blitt manipulert.
Vanlige JWT-claims
- sub: sub (Subject): Identifiserer hovedpersonen — vanligvis en bruker-ID eller e-postadresse.
- iat: iat (Issued At): Unix-tidsstempel som angir når tokenet ble opprettet.
- exp: exp (Expiration): Unix-tidsstempel etter hvilket tokenet ikke lenger er gyldig.
- iss: iss (Issuer): Identifiserer hvem som utstedte tokenet (f.eks. autentiseringsserveren din).
- aud: aud (Audience): Identifiserer den tiltenkte mottakeren av tokenet (f.eks. API-et ditt).
Slik bruker du dette verktøyet
Lim inn en JWT i inndatafeltet. Verktøyet dekoder umiddelbart headeren og payloaden og viser claimene i et lesbart format. Utløpstider konverteres til menneskelesbare datoer. Verktøyet verifiserer også tokenstrukturen og indikerer om formatet er ugyldig.
Er det trygt å lime inn min JWT her?
Ja. Dette verktøyet dekoder JWT-en helt i nettleseren din ved hjelp av JavaScript. Ingen data sendes til noen server. JWT-er bør imidlertid alltid behandles som sensitive legitimasjoner — del aldri produksjonstokener offentlig, post dem i chattemeldinger eller lagre dem i versjonskontroll.
Slik fungerer JWT-autentisering
Når en bruker logger inn, oppretter serveren en JWT som inneholder brukerens identitet og tillatelser, signerer den med en hemmelig nøkkel og returnerer den til klienten. Klienten inkluderer dette tokenet i Authorization-headeren for påfølgende API-forespørsler. Serveren verifiserer signaturen for å sikre at tokenet er autentisk og ikke har blitt endret.
Denne tilnærmingen er tilstandsløs — serveren trenger ikke å lagre sesjonsdata i en database. All nødvendig informasjon er innebygd i selve tokenet. Dette gjør JWT-er ideelle for distribuerte systemer, mikrotjenestearkitekturer og serverløse applikasjoner der delt tilstand er vanskelig å håndtere.
Vanlige JWT-feil
Å lagre sensitiv data (passord, kredittkortnumre) i JWT-payloaden er en kritisk feil. Payloaden er bare Base64-kodet, ikke kryptert — enhver med tokenet kan dekode og lese den. Lagre kun identifikatorer og ikke-sensitive claims i JWT-er.
Å bruke overdrevent lange utløpstider er en annen vanlig feil. Et token som er gyldig i 30 dager gir en angriper 30 dager til å bruke et stjålet token. Hold levetiden for tilgangstokener kort (5–15 minutter) og bruk oppdateringstokener for langvarige sesjoner.
Ofte stilte spørsmål
Hva er forskjellen mellom HS256 og RS256?
HS256 bruker en delt symmetrisk hemmelighet — den samme nøkkelen signerer og verifiserer tokenet. RS256 bruker et asymmetrisk nøkkelpar — en privat nøkkel signerer og en offentlig nøkkel verifiserer. RS256 foretrekkes for distribuerte systemer fordi verifikasjonsnøkkelen kan deles offentlig uten å kompromittere sikkerheten.
Kan en JWT tilbakekalles?
JWT-er er tilstandsløse, så de kan ikke tilbakekalles direkte. Vanlige løsninger inkluderer å vedlikeholde en serverside-blokkliste over tilbakekalte token-IDer, bruke korte utløpstider eller rotere signeringsnøkler. For umiddelbar tilbakekalling bør du vurdere å bruke ugjennomskinnelige tokener med serverside-sesjonslagring i stedet.