Hvad er i en JWT? Dekodning er ikke verificering

Et JSON Web Token (JWT) er tre stykker tekst sat sammen med punktummer: en header, en payload og en signatur. De to første er kun kodet, ikke krypteret, så enhver der har tokenet, kan læse dem. Signaturen gør det muligt for en server at kontrollere, at en betroet part har udstedt tokenet, og at ingen har ændret det. Dekodning af et token fortæller dig, hvad der står i det. Kun verificering fortæller dig, om du skal tro på det.

JWT-dekoderUdløbet token, eller er den gyldig?Prøv gratis

De tre dele

Et token ser sådan ud: header.payload.signature. Den første del af det velkendte eksempeltoken fra jwt.io er:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Hver af de to første dele er JSON konverteret til base64url, en tekstform der er sikker at bruge i URL'er. Den første del dekodes til:

{"alg":"HS256","typ":"JWT"}

Payloaden i samme eksempel dekodes til:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

Payloaden indeholder claims, altså udsagn om brugeren eller sessionen. Signaturen beregnes ud fra de to første dele og en nøgle, så hvis du ændrer ét tegn, passer den ikke længere. Base64url kræver ingen nøgle for at blive vendt tilbage, så læg aldrig en adgangskode, en privat nøgle eller persondata i en payload.

Registrerede claims

RFC 7519, standarden for JWT'er, reserverer nogle få korte claim-navne:

• iss (issuer): hvem der oprettede tokenet.
• sub (subject): hvem tokenet handler om, typisk et bruger-ID.
• aud (audience): den tjeneste tokenet er beregnet til.
• exp (expiration time): tidspunktet, hvorefter tokenet er ugyldigt.
• nbf (not before): det tidligste tidspunkt, hvor tokenet er gyldigt.
• iat (issued at): hvornår tokenet blev oprettet.

Tidspunkter angives som sekunder siden 1. januar 1970 UTC, kaldet Unix-tid. Eksemplet har ingen exp, så det udløber aldrig ifølge standarden. Et rigtigt token bør have en. Andre navne, fx role eller email, hører til applikationen.

Dekodning er ikke verificering

Dekodning deler tokenet ved punktummerne, vender base64url-kodningen og læser JSON'en. Det viser, hvad tokenet påstår, og det gør det samme for et forfalsket token, for enhver kan skrive vilkårlige claims med en vilkårlig signatur.

Verificering genberegner signaturen med den rigtige nøgle og kontrollerer, at den stemmer. Den kontrollerer også, at exp og nbf omslutter det aktuelle tidspunkt, og at iss og aud er de værdier, tjenesten forventer. En app, der læser en role-claim uden at verificere, stoler på den, der har skrevet tokenet. Det er en almindelig fejl.

HS256, RS256 og ES256

Værdien i alg angiver metoden. Tre er almindelige:

• HS256 er HMAC med SHA-256. Én delt hemmelighed både signerer og verificerer, så hemmeligheden skal blive på den server, der udsteder tokens.
• RS256 er en RSA-signatur med SHA-256. Udstederen signerer med en privat nøgle, og alle med den offentlige nøgle kan verificere. Andre tjenester kan kontrollere tokens uden at kunne oprette dem.
• ES256 er en ECDSA-signatur med kurven P-256 og SHA-256. Den virker som RS256 med mindre nøgler og signaturer.

Brug HS256, når én tjeneste både udsteder og kontrollerer sine tokens. Brug RS256 eller ES256, når andre tjenester skal kontrollere tokens, som de ikke selv har udstedt.

Problemer, der opstår, når man stoler på headeren

Headeren skrives af den, der sender tokenet, så verificereren må ikke lade den bestemme reglerne.

1. alg: none. Et token uden signatur kan erklære "alg":"none". Nogle biblioteker accepterede engang sådanne tokens og sprang kontrollen over. Angiv de tilladte algoritmer i din egen kode, og tag dem aldrig fra tokenet.
2. Algoritmeforveksling. En server forventer RS256 og har en offentlig nøgle. En angriber sender et HS256-token, signeret med den offentlige nøgle som HMAC-hemmelighed. En verificerer, der accepterer den algoritme headeren nævner, accepterer det. Bind hver nøgle til præcis én algoritme.
3. Svage hemmeligheder. Angriberen har headeren, payloaden og signaturen, så de kan teste mulige hemmeligheder offline. En kort hemmelighed eller et almindeligt ord falder hurtigt for en sådan liste. RFC 7518 siger, at en HS256-nøgle bør være mindst 256 bit og tilfældig.

Indsætning af et produktionstoken på en hjemmeside

Et gyldigt, ikke-udløbet token virker for den, der har det, indtil det udløber. Behandl det som en adgangskode. Før du indsætter et på en side, så find ud af, om siden sender det til en server. Et værktøj, der kører helt i browserfanen, har ikke brug for det. Du kan kontrollere enhver side ved at følge dens netværkskald i browserens udviklerværktøjer.

Tokens kan normalt ikke tilbagekaldes før udløb, medmindre serveren fører en liste. Hvis et aktivt token lækker, så bed tjenesten om at tilbagekalde sessionen eller skifte sine nøgler. Brug et token fra et testmiljø til fejlfinding, når det er muligt. JWT-dekoderen læser de tre dele i din browserfane, og intet, du indsætter, bliver sendt nogen steder hen.

Webhooks: den samme idé med en delt hemmelighed

De fleste webhook-udbydere sender en HMAC af anmodningens body, beregnet med en hemmelighed, du deler med dem, i en header. Din modtager beregner den samme HMAC og sammenligner de to. Almindelige fejl er små. JSON'en formateres om før hashing, så bytes ændrer sig. Testhemmeligheden bruges mod live-trafik. Eller signaturerne sammenlignes med almindelig strengligestilling, som kan lække timing-oplysninger. Brug en sammenligning med konstant tid.

Webhook-signatur tester beregner signaturen ud fra den hemmelighed og den body, du indsætter, til GitHub, Stripe, Slack, Shopify eller ethvert andet HMAC-skema, så du kan se, om de to værdier stemmer overens.

Hurtige svar

Er en JWT krypteret?

Nej. En standard-JWT er signeret, og enhver kan læse dens header og payload. Det er kun signaturen, der beskytter mod ændringer.

Hvad sker der, hvis jeg redigerer payloaden?

Signaturen passer ikke længere, så en verificerende server afviser tokenet. At læse claims tjekker ikke signaturen, så dekoderen viser stadig din redigerede version.