Når du logger ind på en moderne enkeltsideapplikation (som React eller Vue) eller en mobilapp, har serveren brug for en måde at huske, hvem du er. Traditionelt gjorde den dette ved at gemme et "sessions-id" i en massiv database på serveren og slippe en cookie i din browser. Hver gang du klikkede på en knap, skulle serveren slå dette ID op i sin database. Dette kaldes stateful authentication.
Men i en tid med mikrotjenester og skyskalering blev databaser en flaskehals. For at løse dette har udviklere vedtaget Stateless Authentication via JSON Web Tokens (JWT). Med JWT behøver serveren ikke at huske, hvem du er – din browser fortæller serveren præcis, hvem du er, og bruger kryptografi til at bevise det.
Anatomien af en JWT
Hvis du inspicerer netværkstrafikken efter at have logget ind på en moderne app, vil du sandsynligvis se en "Autorisation: Bearer"-header efterfulgt af en lang, tilfældigt udseende streng af tegn adskilt af to prikker. Det er en JWT.
En JWT består af præcis tre dele: Header.Payload.Signature.
1. Overskriften
Den første del er et Base64URL-kodet JSON-objekt, der blot beskriver tokenet. Det indeholder normalt to egenskaber: typen af token (JWT) og signeringsalgoritmen, der bruges (såsom HMAC SHA256 eller RSA).
2. Nyttelasten (krav)
Den midterste del er også et Base64URL-kodet JSON-objekt. Det er her de faktiske data lever. Disse stykker data kaldes "krav". Det kan f.eks. indeholde dit bruger-id, din rolle (f.eks. "Administrator") og et udløbstidsstempel. Fordi denne nyttelast er knyttet til hver anmodning, ved serveren øjeblikkeligt, hvem du er uden at forespørge i en database.
KRITISK ADVARSEL: Nyttelasten er kun kodet, ikke krypteret. Enhver, der opsnapper en JWT, kan nemt afkode den og læse nyttelasten. Gem aldrig adgangskoder, personnumre eller følsomme data i en JWT-nyttelast.
3. Signaturen
Hvis nogen kan læse og redigere nyttelasten, hvad forhindrer en ondsindet bruger i at ændre deres rolle fra "Bruger" til "Admin"? Svaret er signaturen.
For at oprette signaturen tager serveren headeren, nyttelasten og en meget sikker hemmelig nøgle (kun kendt af serveren) og kører dem gennem en kryptografisk algoritme (som SHA256). Den resulterende hash bliver signaturen.
Når serveren modtager et token tilbage fra klienten, genberegner den signaturen ved hjælp af dens hemmelige nøgle. Hvis brugeren har pillet ved nyttelasten (selv ændret et enkelt bogstav), vil den genberegnet signatur ikke matche signaturen på tokenet, og serveren vil øjeblikkeligt afvise anmodningen som svigagtig.
Inspicer tokens sikkert
Har du brug for at læse nyttelasten af en JWT for at fejlfinde din applikation? Brug vores offline JWT-dekoder til at inspicere kravene med det samme uden at sende dit følsomme token til en fjernserver.
Åbn JWT DecoderHvorfor mikrotjenester elsker JWT'er
Forestil dig et firma som Netflix. De har en godkendelsesserver, en videostreamingserver og en faktureringsserver. Hvis de brugte traditionelle sessioner, ville hver enkelt server konstant skulle kommunikere med en central database for at kontrollere, om en bruger er logget ind.
Med JWT'er signerer godkendelsesserveren tokenet ved hjælp af en privat nøgle. Brugeren sender derefter denne token direkte til videoserveren. Fordi videoserveren har den offentlige nøgle, kan den uafhængigt bekræfte signaturen. Videoserveren ved præcis, hvem brugeren er uden nogensinde at tale med godkendelsesserveren eller en database. Dette gør det muligt for infrastrukturen at skalere uendeligt uden flaskehalse.
The Dark Side: Token Invalidation
JWT'er er ikke perfekte. Deres største styrke (at være statsløs) er også deres største svaghed. Da serveren ikke registrerer aktive tokens, kan du ikke nemt logge en bruger ud eller ugyldiggøre et specifikt token, før det udløber.
Hvis en hacker stjæler en brugers JWT, har hackeren fuld adgang, indtil tokenets udløbstidsstempel løber ud. For at mindske denne risiko bruger sikkerhedsingeniører et to-token-system:
- Adgangstokens: Kortvarige JWT'er (f.eks. 15 minutter) brugt til API-anmodninger.
- Opdater tokens: Langlivede, stateful tokens gemt sikkert, brugt udelukkende til at anmode om nye adgangstokens. Hvis en konto kompromitteres, tilbagekalder serveren Refresh Token, og hackerens Access Token vil naturligvis dø i løbet af 15 minutter.
Ofte stillede spørgsmål (FAQ)
Hvor skal jeg opbevare en JWT på frontend?
Lagring af JWT'er i localStorage gør dem sårbare over for Cross-Site Scripting (XSS) angreb. Det mest sikre sted at gemme en JWT i en webbrowser er inde i en HttpOnly-cookie, som forhindrer JavaScript i at få adgang til den.
Hvad sker der, hvis min servers hemmelige nøgle er lækket?
Katastrofe. Hvis en hacker får din hemmelige HMAC-nøgle eller din private RSA-nøgle, kan de generere gyldige JWT'er med enhver nyttelast, de ønsker. De kunne oprette tokens, der giver sig selv "Super Admin"-privilegier, og din server ville acceptere dem som gyldige. Du skal dreje dine nøgler med det samme.
Er JWT'er hurtigere end sessionscookies?
Ikke nødvendigvis. JWT'er er væsentligt større i filstørrelse end et sessions-id på 32 tegn, hvilket betyder, at de bruger mere netværksbåndbredde på hver anmodning. Deres hastighedsfordel kommer udelukkende fra at omgå databaseopslag på backend.