Hva er inni i en JWT, og hvorfor er det ikke nok å dekode den?

En JSON Web Token (JWT) er tre tekststykker skilt med punktum: en header, en payload og en signatur. De to første er bare kodet, ikke kryptert, så den som har tokenet, kan lese dem. Signaturen lar en server sjekke at en pålitelig part utstedte tokenet, og at ingen har endret det. Å dekode en token forteller deg hva den sier. Først verifisering forteller deg om du kan stole på den.

JWT-dekoderToken utløpt, eller fortsatt gyldig?Gjør det gratis

De tre delene

En token ser slik ut: header.payload.signature. Den første delen av eksempeltokenet fra jwt.io er:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Hver av de to første delene er JSON gjort om til base64url, en tekstform som er trygg å bruke i URL-er. Den første delen dekodes til:

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

Payloaden i samme eksempel dekodes til:

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

Payloaden inneholder claims, som er påstander om brukeren eller økten. Signaturen beregnes ut fra de to første delene og en nøkkel, så endrer du ett tegn, slutter den å stemme. Base64url krever ingen nøkkel for å reverseres, så legg aldri et passord, en privat nøkkel eller personopplysninger i en payload.

Registrerte claims

RFC 7519, standarden for JWT-er, reserverer noen korte navn på claims:

• iss (issuer): hvem som laget tokenet.
• sub (subject): hvem tokenet gjelder, vanligvis en bruker-ID.
• aud (audience): tjenesten tokenet er ment for.
• exp (expiration time): tidspunktet etter som tokenet er ugyldig.
• nbf (not before): tidligste tidspunkt tokenet er gyldig.
• iat (issued at): når tokenet ble laget.

Tidspunkter er sekunder siden 1. januar 1970 UTC, kalt Unix-tid. Eksempelet har ingen exp, så etter standarden utløper det aldri. Et ekte token bør ha en. Andre navn, som role eller email, hører til applikasjonen.

Dekoding er ikke verifisering

Dekoding deler tokenet ved punktumene, reverserer base64url og leser JSON-en. Det viser hva tokenet påstår, og det gjør det samme for et forfalsket token, fordi hvem som helst kan skrive vilkårlige claims med en vilkårlig signatur.

Verifisering beregner signaturen på nytt med riktig nøkkel og sjekker at den stemmer. Den kontrollerer også at exp og nbf omslutter det nåværende tidspunktet, og at iss og aud er verdiene tjenesten forventer. En app som leser en role-claim uten å verifisere, stoler på hvem som helst som skrev tokenet. Det er en vanlig feil.

HS256, RS256 og ES256

Verdien i alg angir metoden. Tre er vanlige:

• HS256 er HMAC med SHA-256. Én delt hemmelighet både signerer og verifiserer, så hemmeligheten må holdes på serveren som utsteder tokenene.
• RS256 er en RSA-signatur med SHA-256. Utstederen signerer med en privat nøkkel, og alle med den offentlige nøkkelen kan verifisere. Andre tjenester kan sjekke tokenene uten å kunne lage dem.
• ES256 er en ECDSA-signatur med kurven P-256 og SHA-256. Den fungerer som RS256, med mindre nøkler og signaturer.

Bruk HS256 når én tjeneste både utsteder og sjekker sine tokener. Bruk RS256 eller ES256 når andre tjenester må sjekke tokener de ikke selv har utstedt.

Problemer som oppstår når man stoler på headeren

Headeren skrives av den som sender tokenet, så verifiseringen må ikke la den bestemme reglene.

1. alg: none. Et token uten signatur kan erklære "alg":"none". Noen biblioteker har tidligere godtatt slike tokener og hoppet over sjekken. Angi de tillatte algoritmene i din egen kode, og hent dem aldri fra tokenet.
2. Forveksling av algoritmer. En server forventer RS256 og har en offentlig nøkkel. En angriper sender et HS256-token signert med den offentlige nøkkelen som HMAC-hemmelighet. En verifiserer som godtar hvilken algoritme headeren nevner, godtar det. Knytt hver nøkkel til nøyaktig én algoritme.
3. Svake hemmeligheter. Angriperen har headeren, payloaden og signaturen, så de kan teste kandidathemmeligheter frakoblet. En kort hemmelighet eller et vanlig ord faller raskt for en slik liste. RFC 7518 sier at en HS256-nøkkel bør være minst 256 bit og tilfeldig.

Å lime inn et produksjonstoken på et nettsted

Et gyldig, ikke-utløpt token fungerer for hvem som helst som har det, helt til det utløper. Behandle det som et passord. Før du limer et inn på et nettsted, finn ut om siden sender det til en server. Et verktøy som kjører helt i nettleserfanen har ingen grunn til det. Du kan sjekke en hvilken som helst side ved å følge nettverksforespørslene i nettleserens utviklerverktøy.

Tokener kan vanligvis ikke trekkes tilbake før de utløper, med mindre serveren fører en liste. Hvis et aktivt token lekker, be tjenesten om å trekke tilbake økten eller bytte ut nøklene. Bruk et token fra et testmiljø til feilsøking der det er mulig. JWT-dekoderen leser de tre delene i nettleserfanen din, og ingenting du limer inn sendes noe sted.

Webhooks: samme idé med en delt hemmelighet

De fleste webhook-leverandører sender en HMAC av forespørselens innhold, beregnet med en hemmelighet du deler med dem, i en header. Mottakeren din beregner den samme HMAC-en og sammenligner de to. Vanlige feil er små. JSON-en formateres på nytt før hashing, så bytene endrer seg. Testhemmeligheten brukes mot ekte trafikk. Eller signaturene sammenlignes med vanlig strenglikhet, som kan lekke informasjon om tid. Bruk en konstant-tid-sammenligning.

Webhook-signaturtesteren beregner signaturen ut fra hemmeligheten og innholdet du limer inn, for GitHub, Stripe, Slack, Shopify eller en hvilken som helst HMAC-ordning, slik at du kan se om de to verdiene stemmer.

Raske svar

Er en JWT kryptert?

Nei. En standard JWT er signert, og hvem som helst kan lese headeren og payloaden. Bare signaturen beskytter den mot endringer.

Hva skjer hvis jeg endrer payloaden?

Signaturen slutter å stemme, så en verifiserende server avviser tokenet. Å lese claims sjekker ikke signaturen, så dekoderen viser fortsatt den endrede versjonen din.