JWT-avkodare

Anatomi av en JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNjAwMDAwMDAwfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Varje segment är kodat med Base64URL (inte standard Base64). Headern har formatet JSON, till exempel {"alg":"HS256","typ":"JWT"}; payloaden har samma format, till exempel {"sub":"1234567890","name":"Alice","iat":1600000000}; och signaturen är en HMAC- eller RSA-signatur för header.payload.

Standardclaims (RFC 7519)

Algoritmer som stöds

Fällan alg: none

Tidiga JWT-bibliotek tillät "alg": "none"-token och godtog dem naivt som giltiga. Gör alltid följande:

• Vitlista de algoritmer som din applikation accepterar.
• Avvisa alg: none ovillkorligen.
• Avvisa alg: HS256 när din verifieringskod förväntar sig RS256 (attacken med ”algoritmförväxling”).

Vad JWT inte är

• Inte krypterat. Headern och payloaden är base64-kodade, vilket är trivialt att avkoda. Lägg aldrig hemligheter i en JWT utan att kapsla in den i JWE.
• Inte återkallbart som standard. När en JWT väl är utfärdad är den giltig fram till exp. För återkallelse behöver du en svartlista eller kort giltighetstid plus uppdateringstoken.
• Inte en ersättning för sessionscookies i alla användningsfall. Ogenomskinliga token som lagras på serversidan är ofta enklare och säkrare.

Vanliga misstag

• Att lita på headern. kid och alg kommer från själva tokenet. En komprometterad server kan sätta dem godtyckligt; validera alltid mot en fast lista.
• Att ignorera avvikelser i nbf och iat. Klockdrift gör att iat > now kan inträffa. Tillåt en liten marginal (30–60 s).
• Att logga hela JWT:er. Payloaden innehåller ofta användar-ID:n, e-postadresser och behörigheter, PII som inte bör hamna i stdout.
• Att använda HS256 med en svag hemlighet. En hemlighet på 16 tecken kan knäckas med brute force på några minuter. Använd minst 256 bitar slumpmässig entropi.