JWT Dekódoló

Mit csinál valójában egy JWT dekódoló

Egy JSON Web Token (JWT) elsőre egy hosszú, átláthatatlan, véletlenszerű karakterláncnak tűnik, de nem titkosított, és nem valamiféle titkos rejtjel. Ez egy tömör, URL-biztos konténer, amely strukturált adatot szállít két fél között. Illessz be egy tokent a fenti dekódolóba, és az eszköz szétbontja a karakterláncot, megmutatva a benne rejlő valódi JSON-t — a metaadatokat, az igényléseket (claims), hogy kinek szól a token, és mikor jár le. Minden a böngésződben zajlik. A token soha nem kerül feltöltésre, naplózásra vagy elküldésre sehova, ami nagyon fontos, amikor élő munkamenet-hitelesítő adatot vizsgálsz.

Három rész, két pont

Minden jólformált JWT három, Base64url-kódolt, pontokkal összekapcsolt karakterlánc: fejléc.hasznosadat.aláírás. Ez az egyetlen pont karakter az, amiből a parserek tudják, hol ér véget az egyik szakasz és hol kezdődik a másik, és ezért utasít vissza egy tokent már a beolvasás előtt, ha a pontok száma nem megfelelő.

A fejléc egy apró JSON objektum, amely magát a tokent írja le. Szinte mindig tartalmazza a typ mezőt (a típust, jellemzően JWT) és az alg mezőt — az aláíró algoritmust, mint például HS256 (HMAC SHA-256-tal) vagy RS256 (RSA SHA-256-tal). A fejléc pontosan megmondja egy ellenőrzőnek, hogyan készült az aláírás.

A hasznos adat (payload) az a rész, amelyre a legtöbben kíváncsiak. Ez is egy JSON objektum, amely az igényléseket (claims) tartalmazza — állításokat a felhasználóról és a tokenről. A specifikáció regisztrált (szabványos, fenntartott nevű), nyilvános és privát (a saját alkalmazásod számára kitalált egyedi nevű) igénylésekre osztja őket. A hasznos adat dekódolása mutatja meg, ki van bejelentkezve, milyen szerepkörrel rendelkezik, és mikor jár le a munkamenete.

Az aláírás a kriptográfiai pecsét. A kódolt fejléc és hasznos adat felett számítják ki, a fejlécben megadott algoritmus és egy titkos vagy privát kulcs segítségével. Mivel mindkét másik szakaszra kiterjed, a fejléc vagy a hasznos adat bármilyen módosítása — akár egyetlen karakteré is — érvényteleníti azt.

A leggyakoribb igénylések

A regisztrált igénylések rövid, hárombetűs nevek, amelyeket az RFC 7519 definiál, hogy a különböző rendszerek együttműködhessenek. Néhány szinte mindenhol felbukkan:

• iss — issuer (kibocsátó): ki állította ki a tokent (az auth szervered vagy identitásszolgáltatód).
• sub — subject (alany): az a szereplő, akiről a token szól, jellemzően egy stabil felhasználói azonosító.
• aud — audience (célközönség): a címzett, akinek a token szól. Egy API-nak el kell utasítania azokat a tokeneket, amelyek célközönsége nem ő maga.
• exp — expiration time (lejárati idő): egy Unix időbélyeg, amely után a tokent nem szabad elfogadni.
• iat — issued at (kiállítás ideje): az Unix időbélyeg, amikor a tokent létrehozták.

Találkozhatsz még a nbf (not before, nem korábban mint) és a jti (egyedi tokenazonosító) mezőkkel is. Az időbélyegek másodpercekben mérve, UTC-ben, 1970 óta futnak, ezért egy olyan dekódoló, amely ezeket ember számára olvasható dátumokká alakítja, megspórolja neked azt a fejszámolást, hogy egy token már lejárt-e.

A dekódolás nem ellenőrzés — ez az a rész, ahol sokan hibáznak

Ez a legfontosabb dolog, amit a JWT-kről meg kell érteni. A dekódolás a tartalom kiolvasását jelenti: ehhez nem kell kulcs, és bárki elvégezheti, aki a birtokában van a tokennek, mert a Base64url egy kódolás, nem titkosítás. A ellenőrzés azt jelenti, hogy bizonyítod, a token hiteles és nem manipulált — azaz újraszámolod az aláírást a megfelelő titkos vagy nyilvános kulccsal, és megnézed, egyezik-e.

Ez az eszköz dekódol. Megmutatja, mit állít a token, nem azt, hogy a token megbízható-e. Egy token lehet hamisított, lejárt, vagy újrajátszott, és még mindig tökéletesen tiszta JSON-ra dekódolódhat. Soha ne hozz jogosultsági döntést kizárólag a dekódolt igénylések alapján. Éles környezetben a szerveroldalon ellenőrzöd az aláírást, megnézed az exp mezőt, és megerősíted, hogy az iss és az aud a várt értékekkel egyezik — egy bevált könyvtár segítségével, soha kézzel írt karakterlánc-összehasonlítással.

A hasznos adat nem páncélszekrény

Mivel a hasznos adat csak Base64url-kódolt, bárki elolvashatja, aki lehallgatja a tokent. Kezeld mindenét úgy, mintha nyilvános lenne. Ne tegyél jelszavakat, teljes bankkártyaszámokat, titkos kulcsokat vagy bármilyen érzékeny személyes adatot JWT igénylésekbe — ha te egy kattintással dekódolhatod itt, akkor bárki más is, aki hozzájut egy másolathoz. Az aláírás a módosítás ellen véd, soha nem az olvasás ellen. Ha valóban el kell rejtened a hasznos adat tartalmát, arra a JWE (titkosított tokenek) való, ami egy teljesen más specifikáció.

Adatvédelem és kapcsolódó eszközök

Egy token megvizsgálása érzékeny művelet, ezért ez a dekódoló teljesen kliensoldalon fut — a feldolgozás sima JavaScript a lapodon, és semmi nem hagyja el a gépedet. Egy munkamenet-token beillesztése egy szerver-alapú eszközbe azt jelenti, hogy egy élő hitelesítő adatot adsz át egy harmadik félnek, amit pontosan el kell kerülnöd. A kódolás alapjaihoz nézd meg Base64 eszközünket, és fedezd fel a többi fejlesztői eszközünket is a további helyben futó segédprogramokért.

Gyakran ismételt kérdések