Vad finns i en JWT, och varför är avkodning inte verifiering?

En JSON Web Token (JWT) är tre textdelar som är sammanfogade med punkter: en header, en payload och en signatur. De två första är bara kodade, inte krypterade, så vem som helst som har token kan läsa dem. Signaturen gör att en server kan kontrollera att en betrodd part har utfärdat token och att ingen har ändrat den. Att avkoda en token visar vad den säger. Först när du verifierar den får du veta om du ska lita på den.

JWT-avkodareHar token gått ut? Är den giltig?Gör det gratis

De tre delarna

En token ser ut så här: header.payload.signature. Den första delen i det välkända exempeltoken från jwt.io är:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Var och en av de två första delarna är JSON omvandlad till base64url, en form av text som är säker att använda i URL:er. Den första delen avkodas till:

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

Payloaden i samma exempel avkodas till:

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

Payloaden innehåller claims, det vill säga påståenden om användaren eller sessionen. Signaturen beräknas från de två första delarna och en nyckel, så om du ändrar ett enda tecken stämmer den inte längre. Base64url kräver ingen nyckel för att vändas, så lägg aldrig ett lösenord, en privat nyckel eller personuppgifter i en payload.

Registrerade claims

RFC 7519, standarden för JWT, reserverar några korta claim-namn:

iss (issuer): vem som skapade token.
sub (subject): vem token gäller, oftast ett användar-ID.
aud (audience): tjänsten som token är avsedd för.
exp (expiration time): tidpunkten efter vilken token är ogiltig.
nbf (not before): tidigaste tidpunkt då token är giltig.
iat (issued at): när token skapades.

Tider anges i sekunder sedan 1 januari 1970 UTC, kallat Unix-tid. Exemplet har ingen exp, så enligt standarden går det aldrig ut. En riktig token bör ha en. Andra namn, som role eller email, hör till applikationen.

Avkodning är inte verifiering

Avkodning delar upp token vid punkterna, vänder base64url och läser JSON. Det visar vad token påstår, och det gör det även för en förfalskad token, eftersom vem som helst kan skriva vilka claims som helst med vilken signatur som helst.

Verifiering beräknar om signaturen med rätt nyckel och kontrollerar att den stämmer. Den kontrollerar också att exp och nbf omger den aktuella tiden, och att iss och aud är de värden som tjänsten förväntar sig. En app som läser en role-claim utan att verifiera den litar på vem som helst som skrev token. Det är ett vanligt misstag.

HS256, RS256 och ES256

Värdet i alg anger metoden. Tre är vanliga:

HS256 är HMAC med SHA-256. En delad hemlighet både signerar och verifierar, så hemligheten måste stanna på servern som utfärdar token.
RS256 är en RSA-signatur med SHA-256. Utfärdaren signerar med en privat nyckel, och vem som helst med den publika nyckeln kan verifiera. Andra tjänster kan kontrollera token utan att kunna skapa dem.
ES256 är en ECDSA-signatur med kurvan P-256 och SHA-256. Den fungerar som RS256 med mindre nycklar och signaturer.

Använd HS256 när en tjänst både utfärdar och kontrollerar sina egna token. Använd RS256 eller ES256 när andra tjänster måste kontrollera token som de inte själva utfärdat.

Problem som uppstår när man litar på headern

Headern skrivs av den som skickar token, så verifieraren får inte låta den bestämma reglerna.

alg: none. En token utan signatur kan deklarera "alg":"none". Vissa bibliotek accepterade en gång sådana token och hoppade över kontrollen. Ange vilka algoritmer som är tillåtna i din egen kod, och hämta dem aldrig från token.
Algoritmförväxling. En server förväntar sig RS256 och har en publik nyckel. En angripare skickar en HS256-token som är signerad med just den publika nyckeln som HMAC-hemlighet. En verifierare som accepterar vilken algoritm headern anger godkänner den. Koppla varje nyckel till exakt en algoritm.
Svaga hemligheter. Angriparen har headern, payloaden och signaturen, så de kan testa kandidathemligheter offline. En kort hemlighet eller ett vanligt ord faller snabbt för en sådan lista. RFC 7518 säger att en HS256-nyckel ska vara minst 256 bitar och slumpmässig.

Att klistra in en produktionstoken på en webbplats

En giltig, ej utgången token fungerar för den som har den, tills den går ut. Behandla den som ett lösenord. Innan du klistrar in en sådan på en sida, ta reda på om sidan skickar den till en server. Ett verktyg som körs helt i webbläsarfliken behöver inte göra det. Du kan kontrollera vilken sida som helst genom att följa dess nätverksanrop i webbläsarens utvecklarverktyg.

Token kan vanligtvis inte återkallas innan de går ut, om inte servern för en lista över dem. Om en giltig token läcker bör du be tjänsten att återkalla sessionen eller byta nycklar. Använd en token från en testmiljö för felsökning när det går. JWT-avkodaren läser de tre delarna i din webbläsarflik, och inget du klistrar in skickas någonstans.

Webhooks: samma idé med en delad hemlighet

De flesta webhook-leverantörer skickar en HMAC av request-kroppen, beräknad med en hemlighet som du delar med dem, i en header. Din mottagare beräknar samma HMAC och jämför de två. Vanliga fel är små. JSON formateras om innan hashning, så byten ändras. Testhemligheten används mot skarp trafik. Eller så jämförs signaturerna med vanlig strängjämförelse, vilket kan läcka tidsinformation. Använd en jämförelse med konstant tid.

Testa webhook-signatur beräknar signaturen från hemligheten och kroppen som du klistrar in, för GitHub, Stripe, Slack, Shopify eller valfritt HMAC-schema, så att du kan se om de två värdena stämmer.

Snabba svar

Är en JWT krypterad?

Nej. En vanlig JWT är signerad, och vem som helst kan läsa dess header och payload. Det är bara signaturen som skyddar den mot ändringar.

Vad händer om jag redigerar payloaden?

Signaturen stämmer inte längre, så en verifierande server avvisar token. Att läsa claims kontrollerar inte signaturen, så avkodaren visar fortfarande din redigerade version.