Hva er et JWT? Slik leser du et JSON Web Token
· 6 min lesing · Tools-Bench Guider
Har du bygd eller feilsøkt noe med moderne autentisering, har du møtt JWT-en: en lang streng med to punktum i, i en Authorization-header eller en informasjonskapsel. JSON Web Tokens er måten tjenester deler ut bevis på identitet som andre tjenester kan kontrollere uten et databaseoppslag.
Formatet er bevisst gjennomsiktig — alle kan lese innholdet i et JWT på sekunder. Den åpenheten er en egenskap, men den overrasker utviklere som trodde tokens var ugjennomsiktige. Her er hvordan du leser et, og hva du faktisk bør se etter.
Tre deler, to punktum
Et JWT er tre Base64url-kodede deler satt sammen med punktum: header.innhold.signatur. Headeren er et lite JSON-objekt som angir signeringsalgoritmen (f.eks. "alg": "RS256") og typen token. Innholdet er den interessante delen — et JSON-objekt med påstander (claims) om hvem tokenet tilhører og hva det gir tilgang til. Signaturen er rå kryptografiske byte som dekker de to første delene.
Fordi Base64url er koding og ikke kryptering, kan headeren og innholdet leses av alle som har tokenet — ingen nøkkel kreves. Det er signaturen som gjør tokenet til å stole på: den beviser at innholdet ble utstedt av den som har signeringsnøkkelen, og at det ikke er endret siden. Å lese et JWT krever ingenting; å stole på det krever at signaturen kontrolleres.
Feltene som betyr noe
Standardfeltene du ser i nesten alle tokens:
- sub (subject) — brukeren eller enheten tokenet gjelder; vanligvis en bruker-ID.
- iss (issuer) — hvem som laget tokenet; den som kontrollerer det, bør sjekke at dette stemmer med forventet autentiseringsserver.
- aud (audience) — hvem tokenet er ment for; hindrer at et token laget for ett API brukes på nytt mot et annet.
- exp (expiration) — Unix-tidsstempelet tokenet er ugyldig etter; feltet du sjekker først når du feilsøker.
- iat (issued at) / nbf (not before) — når tokenet ble laget, og når det blir gyldig.
- Egne felt — roller, tillatelser, e-post, kunde-ID-er; alt utstederen valgte å bygge inn.
Feilsøking med en JWT-dekoder
Det klassiske feilsøkingstilfellet: et API svarer 401, og du vil vite hvorfor. Å dekode tokenet besvarer de fleste tilfellene med en gang — exp-tidspunktet er passert (tokenet er utløpt), aud stemmer ikke med API-et du kaller, sub er ikke brukeren du trodde, eller et rollefelt du forventet, mangler. Alt dette er synlig uten noen hemmelig nøkkel.
Tidsstempler er den vanlige snublesteinen: exp og iat er sekunder siden Unix-epoken, så "exp": 1783123200 betyr ingenting før det er gjort om til en dato. En god dekoder gjør omregningen og varsler deg om utløpte tokens.
Sikkerhetsforbehold verdt å kjenne til
Legg aldri hemmeligheter i innholdet i et JWT. Tokens sendes over nettverk, havner i nettleserens lagring og blir logget av mellomtjenere — og alt i innholdet er klartekst for alle som har tokenet. Personopplysninger, passord eller interne detaljer hører ikke hjemme der.
Å dekode er ikke å kontrollere. En dekoder viser deg hva et token påstår; bare kontroll av signaturen mot utstederens nøkkel beviser at påstandene er ekte og urørte. Serverkode må alltid kontrollere signaturen — og låse den forventede algoritmen. Historiske JWT-angrep fungerte ved å lure naive biblioteker: ved å angi "alg": "none" (som godtok et usignert token), eller ved å bytte et RS256-token til HS256 slik at serveren brukte sin offentlige nøkkel som HMAC-hemmelighet. Moderne biblioteker forsvarer seg mot begge deler hvis de er satt opp til bare å tillate algoritmene du faktisk bruker.
Til slutt er JWT-er ihendehavertokens: den som har et, er den det sier. Derfor har de kort levetid (minutter til timer, kontrollert via exp) og brukes sammen med oppdateringstokens, og derfor må de alltid sendes over HTTPS.
Dekod lokalt, ikke på et tilfeldig nettsted
Et ekte token limt inn i en dekoder er en levende innloggingsnøkkel — limer du det inn på et nettsted som sender det til en server, gir du bort en fungerende nøkkel til kontoen eller API-et ditt. JWT-dekoderen i Tools-Bench tolker alt i nettleseren: tokenet forlater aldri enheten din, ingen forespørselslogger ser det, og den virker uten nett når siden er åpen. For tokens fra produksjon er lokal dekoding ikke en luksus, men det eneste trygge alternativet.
Ofte stilte spørsmål
Kan noen lese JWT-en min hvis de snapper den opp?
Headeren og innholdet, ja — helt enkelt, siden Base64url bare er koding. Det de ikke kan uten signeringsnøkkelen, er å endre den eller forfalske en ny. Konfidensialitet underveis kommer fra HTTPS, ikke fra formatet på tokenet.
Hvorfor sluttet tokenet mitt å virke?
Ni av ti ganger er det utløpt — dekod det og sammenlign exp med klokka nå. Ellers bør du sjekke at iss og aud stemmer med det API-et forventer, og at signeringsnøklene ikke er byttet ut.
Er det trygt å lagre et JWT i localStorage?
Det er omdiskutert. localStorage kan leses av alle skript på siden, så en XSS-feil lekker tokenet; en HttpOnly-informasjonskapsel er immun mot det, men trenger beskyttelse mot CSRF i stedet. Korte utløpstider begrenser skaden uansett.