Når du logger på en moderne enkeltsideapplikasjon (som React eller Vue) eller en mobilapp, trenger serveren en måte å huske hvem du er. Tradisjonelt gjorde den dette ved å lagre en "session ID" i en massiv database på serveren, og slippe en informasjonskapsel i nettleseren din. Hver gang du klikket på en knapp, måtte serveren slå opp denne ID-en i databasen. Dette kalles stateful authentication.
Men i en tid med mikrotjenester og skyskalering ble databaser en flaskehals. For å løse dette tok utviklere i bruk Stateless Authentication via JSON Web Tokens (JWT). Med JWT trenger ikke serveren å huske hvem du er – nettleseren din forteller serveren nøyaktig hvem du er, og bruker kryptografi for å bevise det.
Anatomien til en JWT
Hvis du inspiserer nettverkstrafikk etter å ha logget på en moderne app, vil du sannsynligvis se en "Autorisering: Bærer"-overskrift etterfulgt av en lang, tilfeldig utseende tegnstreng atskilt med to prikker. Det er en JWT.
En JWT består av nøyaktig tre deler: Header.Payload.Signature.
1. Overskriften
Den første delen er et Base64URL-kodet JSON-objekt som ganske enkelt beskriver tokenet. Den inneholder vanligvis to egenskaper: typen token (JWT) og signeringsalgoritmen som brukes (som HMAC SHA256 eller RSA).
2. Nyttelasten (krav)
Den midtre delen er også et Base64URL-kodet JSON-objekt. Det er her de faktiske dataene bor. Disse dataene kalles "krav". Den kan for eksempel inneholde bruker-ID-en din, rollen din (f.eks. «Admin») og et utløpstidsstempel. Fordi denne nyttelasten er knyttet til hver forespørsel, vet serveren umiddelbart hvem du er uten å spørre i en database.
KRITISK ADVARSEL: Nyttelasten er bare kodet, ikke kryptert. Alle som fanger opp en JWT kan enkelt dekode den og lese nyttelasten. Oppbevar aldri passord, personnummer eller sensitive data i en JWT-nyttelast.
3. Signaturen
Hvis noen kan lese og redigere nyttelasten, hva hindrer en ondsinnet bruker fra å endre sin rolle fra "Bruker" til "Administrator"? Svaret er signaturen.
For å lage signaturen tar serveren Header, Payload og en svært sikker Secret Key (kun kjent for serveren), og kjører dem gjennom en kryptografisk algoritme (som SHA256). Den resulterende hasjen blir signaturen.
Når serveren mottar et token tilbake fra klienten, beregner den signaturen på nytt ved å bruke dens hemmelige nøkkel. Hvis brukeren tuklet med nyttelasten (til og med endret en enkelt bokstav), vil den omkalkulerte signaturen ikke samsvare med signaturen på tokenet, og serveren vil umiddelbart avvise forespørselen som uredelig.
Inspiser tokens trygt
Trenger du å lese nyttelasten til en JWT for å feilsøke applikasjonen din? Bruk vår offline JWT-dekoder for å inspisere kravene umiddelbart uten å sende det sensitive tokenet ditt til en ekstern server.
Åpne JWT-dekoderHvorfor mikrotjenester elsker JWT-er
Se for deg et selskap som Netflix. De har en autentiseringsserver, en videostreamingserver og en faktureringsserver. Hvis de brukte tradisjonelle økter, måtte hver enkelt server hele tiden kommunisere med en sentral database for å sjekke om en bruker er pålogget.
Med JWT-er signerer autentiseringsserveren tokenet ved hjelp av en privat nøkkel. Brukeren sender deretter tokenet direkte til videoserveren. Fordi videoserveren har den offentlige nøkkelen, kan den uavhengig bekrefte signaturen. Videoserveren vet nøyaktig hvem brukeren er uten å snakke med autentiseringsserveren eller en database. Dette gjør at infrastrukturen kan skaleres i det uendelige uten flaskehalser.
The Dark Side: Token Invalidation
JWT-er er ikke perfekte. Deres største styrke (å være statsløs) er også deres største svakhet. Fordi serveren ikke registrerer aktive tokens kan du ikke enkelt logge ut en bruker eller ugyldiggjøre et spesifikt token før det utløper.
Hvis en hacker stjeler en brukers JWT, har hackeren full tilgang til tokenets utløpstidsstempel går ut. For å redusere denne risikoen bruker sikkerhetsingeniører et to-token-system:
- Tilgangstokener: Kortvarige JWT-er (f.eks. 15 minutter) brukt for API-forespørsler.
- Oppdater tokens: Langlivede, stateful tokens lagret sikkert, brukt strengt tatt for å be om nye tilgangstokener. Hvis en konto blir kompromittert, tilbakekaller serveren Refresh Token, og hackerens Access Token vil naturlig nok dø i løpet av 15 minutter.
Ofte stilte spørsmål (FAQ)
Hvor bør jeg lagre en JWT på frontend?
Lagring av JWT-er i localStorage gjør dem sårbare for Cross-Site Scripting (XSS)-angrep. Det sikreste stedet å lagre en JWT i en nettleser er inne i en HttpOnly-informasjonskapsel, som hindrer JavaScript i å få tilgang til den.
Hva skjer hvis serverens hemmelige nøkkel lekkes?
Katastrofe. Hvis en hacker får tak i den hemmelige HMAC-nøkkelen eller den private RSA-nøkkelen din, kan de generere gyldige JWT-er med hvilken som helst nyttelast de ønsker. De kan lage tokens som gir seg selv "Super Admin"-privilegier, og serveren din vil godta dem som gyldige. Du må rotere nøklene umiddelbart.
Er JWT-er raskere enn øktinformasjonskapsler?
Ikke nødvendigvis. JWT-er er betydelig større i filstørrelse enn en sesjons-ID på 32 tegn, noe som betyr at de bruker mer nettverksbåndbredde på hver forespørsel. Hastighetsfordelen deres kommer helt fra å omgå databaseoppslag på backend.