Enkel introduksjon til JWT i webapplikasjoner uten å rote til sikkerheten

JWT dukker opp overalt når vi snakker om innlogging, API-er og moderne webapplikasjoner. Mange får det anbefalt tidlig, men få får en rolig og konkret forklaring på hva det er og når det er lurt å ta det i bruk.

Her får du en jordnær gjennomgang av JWT: hva det er, hva det løser, når det er smart å bruke det og hvilke sikkerhetsfeller du bør unngå. Målet er at du skal kunne vurdere JWT bevisst, ikke bare følge en oppskrift.

Hva er JWT, helt kort forklart

JWT står for JSON Web Token. Det er et kort tekstformat som inneholder data (typisk om en innlogget bruker), signert på en måte som gjør det mulig å sjekke om innholdet er blitt endret.

Et JWT består av tre deler: header, payload og signatur. Disse delene er Base64-kodet og satt sammen med punktum, for eksempelxxxxx.yyyyy.zzzzz. Selv om tokenet ser kryptisk ut, er det i utgangspunktet bare lesbar JSON pakket inn.

Hva JWT vanligvis brukes til

Det vanligste bruksområdet er autorisasjon: serveren eller API-et får et token i hver forespørsel og kan avgjøre hvem du er og hvilke rettigheter du har. På den måten slipper serveren å slå opp en sesjon i en database for hver forespørsel.

Et annet bruksområde er kommunikasjon mellom tjenester. En backend kan sende et token til en annen backend, slik at den andre tjenesten kan stole på informasjonen uten å spørre den første hver gang.

Fordeler du faktisk merker i et prosjekt

Den tydeligste fordelen er at tokenet er selvstendig. All informasjon som trengs for å ta en beslutning ligger i tokenet, så lenge den som verifiserer har riktig nøkkel. Det gir mindre avhengighet til sentral lagring for hver sjekk.

En annen praktisk fordel er at JWT fungerer godt på tvers av teknologier. Et token laget i en Node backend kan valideres i en .NET-tjeneste, så lenge de er enige om algoritme og nøkler.

Vanlige misforståelser om JWT

En utbredt misforståelse er at JWT er det samme som sikkerhet. JWT gir en måte å signere og strukturere data på, men alt rundt er fortsatt ditt ansvar: nøkkelhåndtering, lagring, utløpstid og håndtering av kompromitterte tokens.

En annen misforståelse er at tokenet er kryptert. Som standard er et JWT bare kodet, ikke skjult. Innholdet kan leses av hvem som helst som får tak i det, så du bør ikke legge inn sensitive data som passord eller fullt personnummer.

Når JWT er et godt valg, og når det ikke er det

JWT passer godt når du har et API som skal kalles fra flere klienter, eller du har flere tjenester som må stole på den samme innloggingsinformasjonen. Det er også nyttig når du vil skalere horisontalt uten å dele sesjonsdata mellom servere.

Til en enkel nettside med innlogging og noen få sider kan en tradisjonell serversesjon og en trygg cookie være både enklere og ryddigere. Da slipper du å tenke på utløpstid, blacklisting og token-rotasjon i samme grad.

Slik fungerer innlogging med JWT i grove trekk

Et typisk forløp ser slik ut: brukeren sender inn brukernavn og passord til en innloggings-endepunkt. Serveren sjekker legitimasjonen og lager et token med informasjon om brukeren og en utløpstid.

Tokenet sendes til klienten, som lagrer det på en eller annen måte og sender det med iAuthorization-header i senere forespørsler. Serveren validerer signaturen og sjekker utløpstid før den gir tilgang.

Sikker lagring av JWT på klientsiden

Mange eksempler foreslår å lagre tokenet ilocalStorage, fordi det oppleves enkelt. Problemet er at alt som kan nås fra JavaScript også kan stjeles av ondsinnet skript hvis du har en XSS-sårbarhet.

Et tryggere alternativ i mange tilfeller er å lagre selve tilgangstokenet i enHttpOnly-cookie, slik at skript ikke får tak i det direkte. Da må du tenke på CSRF-beskyttelse, men du reduserer risikoen for at tokenet blir stjålet gjennom XSS.

Utløpstid, fornyelse og “refresh tokens”

Et viktig prinsipp er at tilgangstokenet bør leve kort. Et kortlivet token begrenser skaden om det blir lekket. Du kan for eksempel la det vare i minutter i stedet for timer eller dager.

For at brukeren ikke skal bli logget ut hele tiden, brukes ofte et eget fornyelsestoken. Det lagres mer beskyttet, har lengre levetid og brukes bare til å be om nye kortlivede tilgangstokens. Hvis et fornyelsestoken blir mistenkelig, kan du oppheve det på serversiden.

Typiske fallgruver og hvordan du unngår dem

En vanlig felle er å godta svak signeringsalgoritme, eller å la klienten bestemme algoritme og så ikke sjekke det ordentlig på serversiden. Løsningen er å begrense hvilke algoritmer du støtter, og konfigurere det eksplisitt.

En annen felle er å legge inn for mye informasjon i tokenet, slik at det både blir stort og lekkasje-sensitivt. Hold payloaden nøktern: identifikator, roller og andre felt du faktisk trenger ved autorisasjon, ikke hele brukerprofilen.

En enkel sjekkliste før du velger JWT

Før du bestemmer deg, kan du stille deg noen spørsmål: trenger du at flere tjenester kan stole på samme token, eller holder det med én server som husker en sesjon? Hvor krevende er det for deg å administrere utløp, oppheving og nøkkelrotasjon?

Hvis behovet er begrenset og arkitekturen enkel, er det ofte greit å starte med tradisjonelle sesjoner og eventuelt gå over til JWT når kravene endrer seg. Om du går for JWT, bør du sette av litt tid til å forstå sikkerhetskonsekvensene og teste godt.