JWT dekódoló és ellenőrző

A JSON Web Token (RFC 7519) egy tömör, URL-ben is használható formátum, amellyel a szerver igazolja, hogy ki vagy és mit tehetsz. A webes bejelentkezések, API-k és az OAuth 2.0 / OpenID Connect rendszerek használják. Három, ponttal elválasztott részből áll:

1. fejléc (header): az aláírás algoritmusa és a token típusa, például {"alg":"HS256","typ":"JWT"};
2. tartalom (payload): az úgynevezett claimek, például a felhasználó azonosítója és a lejárat;
3. aláírás (signature): a fejléc és a tartalom kriptográfiai aláírása.

Az első két rész csak Base64URL-kódolt, nem titkosított: bárki elolvashatja, akinél a token van. Ezért a JWT-be soha ne tegyél titkos adatot (jelszót, személyes adatot, bankkártyaszámot). A titkosított változat, a JWE öt részből áll, és kulcs nélkül nem olvasható.

Claim	Jelentés
iss	kiállító (issuer), pl. a bejelentkeztető szerver címe
sub	alany (subject), általában a felhasználó azonosítója
aud	címzett (audience), melyik alkalmazásnak szól
exp	lejárat (expiration) – Unix-időbélyeg másodpercben
iat	kiállítás ideje (issued at)
nbf	érvényesség kezdete (not before)
jti	a token egyedi azonosítója (visszavonáshoz)

A dekódoló az időbélyegeket magyar (Europe/Budapest) idő szerint is kiírja, relatív formában is („2 órája lejárt”, „14 perc múlva lejár”). A hozzáférési tokenek (access token) tipikusan 5–60 percig érvényesek, a frissítő tokenek (refresh token) napokig vagy hetekig. Ha egy API 401-es hibát ad, gyakran egyszerűen lejárt a token – ezt itt egy pillantással ellenőrizheted.

A dekódolás nem ellenőrzi, hogy a token valódi-e: bárki készíthet olyan tokent, amelynek a tartalma tetszőleges. A hitelességet az aláírás garantálja, amit a szervernek minden kérésnél ellenőriznie kell.

HMAC-algoritmusnál (HS256, HS384, HS512) a kiállító és az ellenőrző ugyanazt a titkos kulcsot ismeri. Ha megadod a kulcsot, az eszköz a böngésző Web Crypto API-jával kiszámolja az aláírást, és összeveti a tokenben lévővel. A kulcsot szövegként vagy Base64URL-kódolva adhatod meg.

Az aszimmetrikus algoritmusoknál (RS256, ES256, EdDSA) a kiállító privát kulccsal ír alá, az ellenőrzéshez a nyilvános kulcs (gyakran a kiállító JWKS-végpontján) kell; ezt az eszköz jelenleg nem ellenőrzi.

Biztonsági intelmek fejlesztőknek: az "alg": "none" (aláíratlan) tokent soha ne fogadd el; rögzítsd a szerveren, milyen algoritmust vársz; mindig ellenőrizd az exp, aud és iss mezőket; és HMAC-kulcsnak hosszú, véletlen titkot használj.

Egy érvényes hozzáférési token olyan, mint egy belépőkártya: aki megszerzi, a lejáratáig a nevedben használhatja az API-t. Ezért:

• éles (production) tokent és kulcsot ne másolj be ismeretlen weboldalakra – ez az eszköz ugyan nem küld el semmit, de a megszokás veszélyes;
• tesztelésre lejárt vagy fejlesztői környezetből származó tokent használj;
• ha egy éles titkos kulcs nyilvánosságra került (például egy képernyőképen vagy nyilvános kódtárban), azonnal cseréld le, és vond vissza a kiadott tokeneket.

A dekódolás és az ellenőrzés kizárólag a böngésződben történik; a tokent és a kulcsot nem tároljuk és nem továbbítjuk.

Fejlesztés közben a tokent legtöbbször a böngésző fejlesztői eszközeiben találod: a Hálózat (Network) lapon egy API-kérést kijelölve a kérésfejlécek között az Authorization: Bearer eyJ… sorban, vagy az Alkalmazás (Application) lapon a Local Storage, Session Storage vagy a sütik között. Az eyJ kezdet árulkodó: ez a {" Base64URL-kódolt alakja, vagyis egy JSON-objektum eleje.

Ha a token túl hosszú vagy sok adatot tartalmaz, az minden kérésnél terheli a hálózatot; jó gyakorlat csak az azonosításhoz szükséges claimeket tenni bele, a többi adatot a szerveren lekérdezni.

Kijelentkezéskor a JWT nem „hal meg” magától: a lejáratáig érvényes marad, ezért a kritikus rendszerek rövid lejáratot és visszavonási listát használnak.