Sådan fungerer JWT-autentificering — tokens uden sessioner

Sådan fungerer JWT-autentificering — tokens uden sessioner

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs fra venstre mod højre: Login, Tokenudstedelse, Autentificerede forespørgsler.
• Brugerens række og serverens række skiftes, så hver pil enten er brugeren, der leverer noget, eller serveren, der afgør noget.
• De to afvisningsfigurer øverst i login- og forespørgselskolonnen er fejlens slutpunkter — hver beslutning på lærredet fører ind i en af dem.

At bevise, hvem du er

»Brugeren indsender e-mail og adgangskode« og »Serveren verificerer loginoplysningerne mod databasen« er det eneste sted i forløbet, hvor en adgangskode findes. »Er loginoplysningerne gyldige?« deler sig i den lykkelige vej og »Login afvist«. Det er helt almindelig autentificering — JWT-delen begynder, når tjekket af loginoplysningerne er lykkedes.

At udstede tokenet

»Serveren bygger header, payload og signatur« er diagrammets hjerte. Headeren navngiver signeringsalgoritmen; payloaden bærer de claims — bruger-id, udløb og eventuelle scopes; signaturen binder dem sammen, så tokenet ikke kan ændres, uden at det opdages. »Serveren signerer tokenet med sin hemmelige nøgle« er den handling, der gør det troværdigt: kun en server, der har hemmeligheden, kan lave en gyldig signatur. »Klienten modtager JWT'et og gemmer det« overdrager artefaktet til klienten, hvor det lever, indtil det udløber.

Stateless verifikation

»Klienten sender JWT'et i Authorization-headeren« indleder den gentagne del af forløbet, og »Serveren verificerer signaturen med sin hemmelige nøgle« er grunden til, at det skalerer: at genberegne en signatur er en beregning, ikke et databaseopslag, så der er intet centralt sessionslager at spørge. »Er signaturen gyldig og ikke udløbet?« lægger tidstjekket til og sender ugyldige eller udløbne tokens videre til »Forespørgsel afvist med 401« og gyldige til »Serveren stoler på claims og behandler forespørgslen«.

Key relationships and takeaways

• Et JWT er tre dele — header, payload, signatur — samlet med punktummer; payloaden kan læses, men afslører ændringer.
• Signaturen forvandler identitet til en rettighed: det at have et gyldigt, ikke-udløbet token er det, der autentificerer forespørgslen.
• Verifikationen er stateless — at genberegne signaturen erstatter sessionsopslaget.
• Tokenet skal gemmes sikkert af klienten og sendes med hver forespørgsel, så dets udløb er den reelle sikkerhedsgrænse.
• JWT og OAuth passer sammen: OAuth afgør, hvad klienten må gøre, og JWT er ét udbredt format for det token, der bærer afgørelsen.

When to use this visual

• At lære et nyt backendteam, hvorfor der ikke er brug for en sessionstabel, og hvad signaturen faktisk beviser.
• At vælge mellem JWT og serverside-sessioner til en tjeneste, hvor horisontal skalering gør delt tilstand besværlig.
• At gennemgå et tokens claims — udløb, udsteder, modtager — før du stoler på det i en microservice.

Sådan fungerer det

1. Skriv de claims ned, jeres tokens faktisk bærer

   Tilføj på trinnet »Serveren bygger header, payload og signatur« de reelle claims, I udsteder — sub, exp, iss, aud og eventuelle scopes — så diagrammet dokumenterer jeres tokenkontrakt.

2. Tilføj fornyelsesforløbet

   Indsæt refresh-tokenvejen efter udløbet: klienten fremviser et langlivet refresh-token, serveren udsteder et nyt adgangstoken, og sessionen fortsætter uden et nyt login.

3. Navngiv jeres strategi for signeringsnøgler

   Notér jeres nøglehåndtering på signeringstrinnet — én delt hemmelighed (HS256) eller et nøglepar med offentlig og privat nøgle (RS256) — for det valg afgør, hvem der kan verificere tokenet.

4. Tilføj fejlgrenene

   Tag udløbne, misdannede og manipulerede tokens med som eksplicitte slutpunkter, så diagrammet dækker de afvisninger, jeres API faktisk returnerer.

Ofte stillede spørgsmål

Hvad er et JWT, og hvad indeholder det?

Et JSON Web Token er en streng af tre punktadskilte dele: en header, der angiver signeringsalgoritmen, en payload af claims om brugeren og tokenets levetid, og en signatur. Headeren og payloaden er base64-kodet JSON — læsbar for alle — og signaturen er det, der forhindrer, at de bliver ændret uden signeringsnøglen.

Hvorfor kaldes JWT-autentificering stateless?

Fordi serveren ikke gemmer noget om sessionen. Hver forespørgsel ankommer med tokenet, og serveren verificerer signaturen og udløbet på stedet. Der er ingen sessionstabel at forespørge og ingen tilstand at replikere på tværs af servere, og det er dét, der gør fremgangsmåden horisontalt skalerbar. Prisen er, at et token ikke kan trækkes tilbage, før det udløber, uden ekstra maskineri.

Er et JWT sikkert, når alle kan læse payloaden?

At læse og at stole på er to forskellige ting. Payloaden er ikke krypteret — læg ikke hemmeligheder i den — men signaturen betyder, at enhver ændring gør tokenet ugyldigt, så en klient kan ikke ændre sine egne claims. Transporten sikres ved, at tokenet rejser inde i HTTPS, og de data, det giver adgang til, er beskyttet ved, at ressourceserveren håndhæver de claims.

Hvordan hænger JWT og OAuth sammen?

De løser hver sin halvdel af problemet. OAuth er autorisationsprotokollen — hvordan en klient får tilladelse og et token. JWT er et tokenformat. I praksis er OAuth-adgangstokens ofte JWT'er: autorisationsserveren signerer et JWT, der bærer de scopes, og ressourceservere verificerer det. Dette lærred dækker autentificeringshalvdelen; den visuelle forklaring om OAuth dækker delegeringshalvdelen.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det JWT-lærred, du ser her, som dit eget diagram, omdøb klienten og serveren til jeres egne tjenester, og notér jeres egne claims.

Redigér dette diagram i QueryChart (FlowJam)