CodeKitHub
Kódoló eszközök

JWT dekódoló

Utolsó frissítés:

Illessz be bármilyen JWT-t (JSON Web Token), és nézd meg a fejlécét és a tartalmát azonnal dekódolva és formázva — beleértve azt is, hogy lejárt-e. Minden a böngésződben történik: a token soha nem kerül elküldésre sehova, és nem történik aláírás-ellenőrzés (ez az eszköz csak dekódol, nem ellenőrzi, hogy a token valódi-e).

Header

Payload

Decoded entirely in your browser — no signature verification, and the token is never sent anywhere.

Mi ez az eszköz?

A JWT (JSON Web Token) egy tömör, URL-biztonságos sztring, amelyet igénylések (claims) két fél közötti szállítására használnak — leggyakrabban bejelentkezés utáni hitelesítési tokenként. Három, ponttal elválasztott részből áll: egy fejlécből (algoritmus és token típusa), egy tartalomból (a tényleges igénylések — felhasználói azonosító, szerepkörök, lejárat stb.), és egy aláírásból (amellyel a szerver ellenőrzi, hogy a tokent nem manipulálták).

A fejléc és a tartalom csupán Base64URL-kódolt JSON — nincs titkosítva —, így bárki dekódolhatja és elolvashatja titkos kulcs nélkül. Csak az aláírás ellenőrzéséhez kell titkos kulcs. Pontosan ezt teszi ez az eszköz: dekódolja az olvasható részeket, és formázott JSON-ként jeleníti meg őket, anélkül, hogy megpróbálná ellenőrizni az aláírást.

A JWT-ket az RFC 7519 szabványosítja, az aláírási réteget (JWS) pedig külön az RFC 7515 definiálja — hasznos referenciák, ha szükséged van a hivatalos, regisztrált igénylések listájára, mint az exp, iat, sub és aud.

Miért érdemes használni?

  • Azonnal olvasható fejléc és tartalom, JSON-ként formázva — nincs többé kézi sztring-darabolás és Base64-dekódolás.
  • Automatikus lejárat-ellenőrzés: ha a tartalom tartalmaz egy „exp” igénylést, az olvasható dátummá alakul, és jelöli, hogy lejárt-e vagy érvényes.
  • Egykattintásos másolás a fejlécnek vagy a tartalomnak külön-külön.
  • 100%-ban kliensoldali — a token helyben kerül dekódolásra és soha nem kerül továbbításra, biztonságosan használható éles rendszerből származó tokenekkel is.
  • Nem történik és nincs is állítva aláírás-ellenőrzés — ez egy hibakereső/vizsgáló eszköz, nem érvényesítő.

Használati útmutató

  1. Illeszd be a JWT-det a mezőbe (a teljes sztringet, mindhárom, ponttal elválasztott résszel együtt).
  2. A fejléc és a tartalom automatikusan dekódolódik, ahogy gépelsz.
  3. Ellenőrizd a lejárati sort, ha a token tartalmaz „exp” igénylést — megmutatja a pontos dátumot és azt, hogy a token lejárt-e.
  4. Kattints a „Másolás” gombra bármelyik mező alatt, hogy az adott részt JSON-ként másold.

Példa

Bemenet

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkpvaG4gRG9lIiwiZXhwIjoxNzAwMDAwMDAwfQ.dQw4w9WgXcQ

Kimenet

Header: {"alg": "HS256"}
Payload: {"sub": "1234", "name": "John Doe", "exp": 1700000000}

Az aláírás (harmadik rész) soha nincs dekódolva vagy ellenőrizve — ez egy átlátszatlan hash, amelyet a szerveroldal használ a hitelesség ellenőrzésére.

Gyakorlati tippek

  • „Érvénytelen token” hibák hibakeresése: dekódold először a tartalmat, hogy ellenőrizd az „exp” igénylést — egy lejárt token a leggyakoribb ok, és ez nem mindig nyilvánvaló csak a hibaüzenetből.
  • Ellenőrizd, hogy egy külső API tokenje mit tartalmaz valójában: sok API átlátszatlannak tűnő JWT-t ad vissza hozzáférési tokenként — dekódold itt, hogy lásd, milyen jogosultságokat, felhasználói azonosítót vagy lejáratot kap valójában az integrációd.
  • Soha ne feltételezd, hogy egy JWT titkosított: ha érzékeny adatot (email, belső azonosítók) látsz egy dekódolt tartalomban fejlesztés közben, az jelzi, hogy az adatot inkább szerveroldalra kellene helyezni, nem pedig a kliensre bízni, hogy nem olvassa el.

Gyakori igénylések, amelyeket egy tartalomban láthatsz

IgénylésJelentés
subSubject — általában a token által képviselt felhasználó azonosítója
expLejárati idő (Unix időbélyeg) — a token ezután érvénytelen
iatIssued at — mikor jött létre a token
issIssuer — melyik szolgáltatás/szerver bocsátotta ki a tokent
audAudience — melyik szolgáltatásnak szánták a tokent
role / roles / scopeEgyéni igénylések — a felhasználónak adott jogosultságok vagy szerepkörök (nem része a JWT szabványnak, de rendkívül gyakori)

Gyakori kérdések

Ellenőrzi ez az eszköz a JWT aláírását?

Nem. Az aláírás ellenőrzéséhez szükség van a token aláírásához használt titkos vagy nyilvános kulcsra, amellyel csak a kibocsátó szerver rendelkezik. Ez az eszköz csak a fejlécet és a tartalmat dekódolja — az emberi szem számára olvasható részeket —, így megvizsgálhatod az igényléseket és a lejáratot bármilyen kulcs nélkül.

Biztonságos ide beilleszteni egy valódi, éles JWT-t?

A dekódolás teljes egészében a böngésződben történik JavaScript segítségével — a token soha nem kerül elküldésre semmilyen szerverre, a miénkre sem. Ennek ellenére kezeld a tokeneket úgy, mint a jelszavakat: ne illeszd be őket olyan eszközökbe, amelyekben nem bízol, és kerüld a dekódolt tokenekről készült képernyőképek megosztását, amelyek érzékeny igényléseket tartalmaznak.

Miért olvashatja el bárki a JWT-m tartalmát jelszó nélkül?

Ez tervezésből fakad — egy JWT fejléce és tartalma Base64URL-kódolt, nem titkosított. A kódolás nem biztonság; csupán URL-biztonságossá teszi a JSON-t az átvitelhez. Soha ne tegyél titkokat (jelszavakat, bankkártyaszámokat) közvetlenül egy JWT tartalmába — feltételezd, hogy bárki, akinek van tokenje, elolvashatja a tartalmát.

Mit jelent az „exp” igénylés, és miért fontos?

Az „exp” a token lejárati ideje, Unix időbélyegként (1970 óta eltelt másodpercekben). A szerverek elutasítják a JWT-t, miután ez az idő eltelt, ami újra-hitelesítésre kényszeríti a klienst. Ez az eszköz olvasható dátummá alakítja, és jelöli, ha már lejárt, ami hasznos a „miért jelentkeztem ki magamtól” típusú problémák hibakeresésénél.

A tokenem JSON elemzési hibát mutat — miért?

Vagy a sztring nem érvényes JWT (pontosan három, ponttal elválasztott résznek kell lennie), vagy csonkult vagy módosult — gyakori ok, hogy a token véletlenül több sorra töredezett, vagy hiányoznak a záró karakterek másoláskor.

Kapcsolódó eszközök