JSON Web Token (JWT) dekódolása

Mi az a JWT (JSON Web Token)?

A JSON Web Token, rövidítve JWT (ejtsd: "dzsot"), egy kompakt formátum, amelyet az RFC 7519 definiál, és lehetővé teszi állítások (claims) biztonságos továbbítását két fél között. A JWT, vagy JWT token, ma a domináns formátum az autentikált identitás továbbítására HTTP API-kban. Egy JWT egy ASCII karakterláncként jelenik meg, amely három, pontokkal elválasztott szegmensből áll:

header.payload.signature

Minden szegmens Base64URL kódolású, ami a Base64 egy változata = padding nélkül, ahol a + jelet -, a / jelet pedig _ helyettesíti, hogy URL-ekben vagy HTTP fejlécekben további kódolás nélkül szerepelhessen.

Egy JWT felépítése

Egy json web token három jól elkülöníthető részből áll, amelyek mindegyike pontos szerepet játszik az autentikációs mechanizmusban:

1. Header (Fejléc)

A fejléc egy JSON objektum, amely leírja, hogyan van aláírva a token. Tartalmazza legalább:

• alg (algorithm): a használt aláírási algoritmus. Tipikus értékek: HS256, RS256, ES256, EdDSA.
• typ (type): a token típusa, szinte mindig "JWT".
• kid (key ID): opcionális, azonosítja, melyik kulcsot kell használni az aláírás ellenőrzéséhez. Hasznos forgó kulcskészlet (JWKS) esetén.

2. Payload (Adattartalom)

A payload tartalmazza a claim-eket, azaz azokat az állításokat, amelyeket a kibocsátó tesz a felhasználóról vagy a munkamenetről. Az RFC 7519 hét szabványos claim-et definiál (registered claims):

• iss (issuer): ki bocsátotta ki a tokent, például "https://accounts.google.com".
• sub (subject): kié a token, a gyakorlatban a felhasználó azonosítója.
• aud (audience): kinek szól a token. Megakadályozza, hogy egy "A" API-hoz kiadott tokent a "B" API elfogadjon.
• exp (expiration time): Unix időbélyeg, amely után a token már nem érvényes.
• nbf (not before): időbélyeg, amely előtt a token még nem aktív.
• iat (issued at): a token kibocsátásának időbélyege.
• jti (JWT ID): a token egyedi azonosítója, visszavonáshoz és az újrajátszásos támadások megelőzéséhez használják.

Ezekhez a szabványos claim-ekhez általában hozzáadódnak az alkalmazás saját egyedi claim-jei (roles, scope, tenant_id, email, permissions...).

3. Signature (Aláírás)

Az aláírás egy kriptográfiai lenyomat, amelyet a base64url(header) + "." + base64url(payload) alapján számítanak ki egy kulcs segítségével. Ez bizonyítja, hogy a kibocsátás óta senki sem módosította a fejlécet vagy a payloadot. A leggyakoribb algoritmusok:

• HS256 / HS384 / HS512: szimmetrikus HMAC-SHA aláírás. Egy közös titkos kulcs a kibocsátó és az ellenőrző között. Egyszerű, de nem alkalmas, ha egynél több fogyasztó van.
• RS256 / RS384 / RS512: aszimmetrikus RSA aláírás. A kibocsátó a privát kulcsával ír alá, bármely fogyasztó ellenőrizheti a megfelelő publikus kulccsal. Az OAuth2 és OpenID Connect de facto szabványa.
• ES256 / ES384 / ES512: aszimmetrikus ECDSA aláírás. Ugyanazok a tulajdonságok, mint az RS256-nál, de sokkal rövidebb kulcsokkal és aláírásokkal.
• EdDSA (Ed25519): modern, gyors és kompakt aszimmetrikus aláírás.

Ismételten: az aláírás az integritást védi, nem a bizalmasságot. A payload olvasható marad bárki számára, aki birtokolja a tokent.

Miért kell dekódolni egy JWT-t?

A jwt token decode művelet több konkrét igényt is kielégít egy fejlesztő vagy biztonsági mérnök számára:

• Autentikációs hibakeresés: az API-ja 401-es vagy 403-as hibát ad vissza, és látni szeretné, mi van valójában a payloadban (sub, scope, roles, exp) ahelyett, hogy találgatna.
• Claim-ek ellenőrzése: megerősíteni, hogy a token valóban tartalmazza-e az elvárt állítást (például tenant_id vagy permissions), mielőtt az autorizációs lánc más részein keresné a hibát.
• Lejárat ellenőrzése: az exp időbélyeg emberileg olvasható dátummá alakítása annak megerősítésére, hogy a token valóban lejárt, vagy éppen ellenkezőleg, még érvényesnek kellene lennie.
• Biztonsági audit: megbizonyosodni arról, hogy egy harmadik féltől származó szolgáltatás nem szivárogtat-e érzékeny információkat a payloadban (e-mailek, belső azonosítók, személyes adatok).
• Oktatás és megértés: konkrétan látni, hogyan néz ki egy OAuth szolgáltatótól (Google, Auth0, Keycloak, AWS Cognito) érkező jsonwebtoken, hogy a dokumentációba való mélyebb belemerülés nélkül megértse a mechanizmust.
• Publikus tokenek felfedezése: logokban, sütikben vagy elfogható OAuth üzenetváltásokban talált JWT-k vizsgálata.

Dekódoló vs. Ellenőrző: a kritikus különbség

A két művelet hasonlónak tűnhet, de a biztonsági garanciák tekintetében semmi közük egymáshoz:

• Egy JWT dekódolása a karakterlánc . mentén történő felosztásából és az első két szegmensre alkalmazott fordított Base64URL műveletből áll. Ez egy egyszerű olvasás, amelyre bármilyen háromsoros szkript képes. Semmilyen aláírás-ellenőrzés nem történik.
• Egy JWT ellenőrzése az aláírás újraszámításából áll a fejléc, a payload és egy kulcs alapján, majd az eredmény összehasonlításából a tokenben lévő aláírással. Ez az, ami garantálja, hogy a tokent nem hamisították meg.

Gyakorlati konklúzió: a dekódolás nem jelent bizalmat. Amíg az aláírást nem ellenőrizték a megfelelő kulccsal, a payload tartalma teljesen hamis is lehet. A bizalmi fázishoz használja a JWT Ellenőrzőnket.

Hogyan kell használni

1. Szerezze meg a vizsgálni kívánt JWT-t, például egy Authorization: Bearer <jwt> fejlécből, egy munkamenet-sütiből (cookie), a böngésző localStorage-ából vagy egy alkalmazáslogból.
2. Illessze be a teljes karakterláncot a beviteli mezőbe. A három szegmensnek pontokkal elválasztva kell maradnia.
3. Az eszköz azonnal megjeleníti a formázott JSON-ként dekódolt fejlécet (header), az algoritmussal és a típussal együtt.
4. Ezután a payload kerül dekódolásra és megjelenítésre. Itt láthatja az összes szabványos és egyedi claim-et.
5. Az eszköz jelzi az aláírási információkat is (deklarált algoritmus, hossz), anélkül, hogy ellenőrizné azt.
6. Annak megerősítéséhez, hogy a tokent nem hamisították meg, váltson át a JWT Ellenőrzőnkre a publikus kulcs vagy az elvárt titok használatával.

A teljes dekódolás az Ön böngészőjében, JavaScript segítségével történik: a tokent soha nem küldjük el szervereinkre.

JWT és biztonság: elkerülendő csapdák

Néhány aranyfontosságú szabály a JWT-k éles környezetben való használatához:

• Szerveroldalon mindig ellenőrizze az aláírást, mielőtt bármilyen jogosultságot adna. JWT Ellenőrzőnk pontosan ezt a műveletet szemlélteti.
• Publikus API-khoz részesítse előnyben az RS256-ot vagy az ES256-ot a HS256-tal szemben. Az aszimmetrikus aláírás elkerüli, hogy egy titkot kelljen megosztani a kibocsátó and minden fogyasztó között.
• Mindig tartsa be az exp claim-et. Egy lejárat nélküli vagy túl hosszú lejáratú JWT időzített bomba szivárgás esetén.
• Validálja az iss és aud értékeket szerveroldalon, hogy elkerülje, hogy egy másik szolgáltatáshoz kiadott legitim tokent tévedésből elfogadjanak.
• Utasítsa el az alg: "none" beállítást az ellenőrzésnél. Ez egy klasszikus sebezhetőség, amely lehetővé teszi a támadók számára tetszőleges payload létrehozását.
• Alkalmazzon rövid élettartamokat (például 15 perc), és párosítsa szerveroldalon visszavonható, hosszabb élettartamú refresh tokennel.

Példa dekódolt JWT-re

Íme egy tipikus JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Dekódolás után íme a tartalma:

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

// Payload
{
  "sub": "123",
  "name": "John",
  "iat": 1516239022
}

// Signature (bináris, Base64URL kódolással)
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Hol találhatok másolható JWT-t?

A gyakorlatban egy megfejtendő (azaz dekódolandó) JWT leggyakrabban az alábbi helyekről származik:

• HTTP Süti (Cookie): nyissa meg a fejlesztői eszközöket (F12), az Application vagy Storage fület, majd a Cookies részt. Keressen access_token, jwt, session vagy hasonló nevű sütit.
• localStorage / sessionStorage: ugyanaz a panel, Local Storage szakasz. Sok SPA itt tárolja a tokent token vagy auth kulcs alatt.
• Authorization fejléc: Network fül, válasszon ki egy API kérést, olvassa ki az Authorization: Bearer <jwt> fejlécet. Csak a Bearer utáni részt másolja ki.
• Szerverlogok: a JWT néha megjelenik egy gateway vagy reverse proxy naplóiban (éles környezetben kerülendő, de hibakeresésnél hasznos).

Gyakran ismételt kérdések

Kérés példa

curl -X POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"..."}'

Bemeneti séma

Végpontok

• GET https://cdrn.fr/api/v1/tools - listázza az összes elérhető eszközt
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - lekéri ezen eszköz sémáját
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - végrehajtja ezen eszközt JSON payloaddal