Bontson le egy JSON Web Tokent header, payload és signature részekre, vizsgálja meg a claimeket, és opcionálisan ellenőrizze az aláírást egy secret vagy publikus kulcs ellen. Minden helyben fut az ön böngészőjében.
Illesszen be egy tokent a mezőbe, a három doboz élőben frissül (a bevitel debounce-olt, körülbelül 300 ms).
100% a böngészőjében: Ez az eszköz tiszta HTML+JavaScript. Az ön JWT-jét, secretjét és publikus kulcsát teljes egészében az ön gépén dolgozzuk fel, és sosem küldjük szervernek.
Header
bevitelre vár ...
Payload
bevitelre vár ...
Signature
bevitelre vár ...
Aláírás ellenőrzése (opcionális)
A HS256/HS384/HS512 megosztott secretet igényel. Az RS*, PS* és ES* PEM formátumú publikus kulcsot használ (SPKI / BEGIN PUBLIC KEY). Az Ed25519 modern böngészőkben működik.
Készen áll az ellenőrzésre
Tipp: a valódi éles validációért az ellenőrzés a szerver auth-rétegébe való, nem a böngészőbe. Ezt az eszközt hibakeresésre, reverse engineeringre és tanulásra szánjuk.
Mi az a JWT?
A JSON Web Token (JWT, kiejtése "jot") az RFC 7519-ben meghatározott kompakt, aláírt JSON-objektum. Claimeket szállít két fél között, jellemzően egy auth-szerver és egy API között. A szerver a sikeres hitelesítés után állítja ki a tokent, a kliens pedig minden API-híváshoz csatolja az `Authorization: Bearer ...` headeren keresztül.
A JWT három base64url-kódolt részből áll, amelyeket pontok kapcsolnak össze. Nincsenek titkosítva, csak aláírva. Aki birtokolja a tokent, elolvashatja a tartalmát, ezért jelszavak és más titkok sosem kerülhetnek a payloadba.
A szerveroldali sessionekkel szembeni előny: a JWT self-contained. Egy API-szerver az auth-szerver megkérdezése vagy session-store lekérdezése nélkül validálhatja a tokent és olvashatja ki a jogosultságokat. Ez kiválóan skálázódik horizontálisan, viszont az egyes tokenek lejárat előtti visszavonásának lehetőségébe kerül.
Header, payload, signature magyarázata
Minden JWT három részből áll, amelyeket egy-egy pont köt össze:
Header: kis JSON-objektum `alg`-gal (algoritmus, pl. HS256, RS256, ES256) és `typ`-pal (általában "JWT"). Néha `kid` (key ID) is van, utalva arra, melyik kulcsot használtuk az aláíráshoz.
Payload: a claimeket tartó JSON-objektum. A standard mezők az `iss` (kibocsátó), `sub` (subject), `aud` (audience), `exp` (lejárat), `nbf` (not before), `iat` (kibocsátási idő) és `jti` (egyedi token-ID). Egyéni mezők is megengedettek mellettük.
Signature: a `base64url(header) + "." + base64url(payload)` felett a beállított algoritmussal számítva. Védi az integritást: a kulcs nélkül a tartalom észrevétlenül nem módosítható.
Fontos: a base64url kódolás, nem titkosítás. A header és a payload bárki számára olvasható.
JWT és session sütik összehasonlítása
Mindkét megközelítés egy hitelesített állapotot tart fenn, de eltérő módon:
Session süti: átláthatatlan azonosító, a szerver ezzel keresi ki a teljes állapotot a session-store-ból. A visszavonás azonnali, viszont minden kérés egy keresésbe kerül.
JWT: maga hordozza az állapotot, csak aláírás védi. Nem szükséges keresés, ideális mikroszolgáltatási architektúrákhoz, viszont a lejárat előtti visszavonás allow/deny listát igényel.
Méret: a JWT-k jellemzően 300 és 1500 byte között vannak. A session-azonosítók általában 32 byte körül. Sok API-hívásnál a JWT mérete sávszélességben összeadódik.
Tárolás: a sütik (HttpOnly, Secure, SameSite) a böngésző világában biztonságosabb tárolási hely. A localStorage XSS-nek van kitéve.
Ökölszabály: tisztán szerveroldali alkalmazásokhoz session, API-átjárókhoz és mobil backendekhez JWT, ideális esetben rövid élettartammal és refresh-token folyamattal.
JWT-biztonság: mit tegyünk az `algorithm: none`-nal?
A JWT-k az elmúlt években több látványos könyvtárhibát kaptak. A legnagyobb buktatók:
`alg: none`: több könyvtár korábban elfogadta az aláíratlan tokeneket, ha a header ezt állította. Megoldás: sose engedélyezze a `none`-t, az engedélyezett algoritmust a szerveren rögzítse.
HS256/RS256-keveredés: a támadó az RSA publikus kulccsal mint HMAC secrettel ír alá egy tokent, a szerver pedig HS256-ként validálja RS256 helyett, és átverhető. Védekezés: az engedélyezett `alg` a szerveren rögzített.
`kid` injection: a `kid` mező egy kulcsra mutat, de ha nincs sanitizálva, path traversalhez vagy SQL injectionhez vezethet. Kezelje az értéket nem megbízható bemenetként.
Gyenge secretek: a "secret" vagy "password" kulcsú HS256 tokenek brute force-szal másodpercek alatt megtörhetők. Használjon legalább 256 véletlen bitet, ideális esetben `crypto.getRandomValues()` vagy `/dev/urandom` forrásból.
Hosszú élettartam: minden kibocsátott JWT lejáratig érvényes, akkor is, ha a felhasználó már "kijelentkezett". Használjon rövid élettartamokat (15 perc) refresh-token folyamattal vagy deny listát érzékeny végpontokhoz.
Az OWASP cheatsheetek és az RFC 8725 (JWT Best Current Practices) kötelező olvasmány.
Hogyan validáljak egy JWT-t?
A teljes validáció sokkal többet jelent, mint az aláírás ellenőrzése. A szerverkódban a sorrend:
Header értelmezése, az `alg` ellenőrzése allowlist ellen (pl. csak RS256).
Az aláírás ellenőrzése a kibocsátó konfigurációjához tartozó kulccsal. JWKS esetén használja a `kid`-et a kereséshez, de először az értékeit fehérítse listára.
Standard claimek ellenőrzése: az `iss` egyezzen a várt kibocsátóval, az `aud` tartalmazza a saját audience-et, az `exp` a jövőben legyen, az `nbf` és `iat` a múltban (kis órareltérés-tűréssel).
Saját claimek (szerepkörök, tenant ID, scopes) érvényesítése az üzleti modell ellen.
Ha korai visszavonásra van szükség, ellenőrizze a deny / logout listát.
Bízzon egy bevett könyvtárban (jose, jjwt, jsonwebtoken stb.), ne saját kézzel írt kódban. A kriptográfia nem hobbiprojekt.
Auth backend hostolása a KernelHostnál
A JWT-kibocsátónak és a resource-szervernek megbízható, alacsony késleltetésű backendre van szüksége. A KernelHost saját VPS-eket és dedikált szervereket üzemeltet Frankfurt FRA01-ben DDoS-védelemmel, IPv4 + IPv6 és 1 Gbit/s uplinkkel. Alacsony RTT az európai végfelhasználók felé, fair árazás, vendor lock-in nélkül. Cégszékhely Bécs (AT), adatközpont Frankfurt (DE).
JWT GYIK
Biztonságos éles JWT-t illeszteni ebbe az eszközbe?
Igen. Az oldal statikus HTML JavaScripttel, szerveroldali logika nélkül. A tartalom sosem hagyja el a böngészőt, és a localStorage-ban sem tároljuk (csak a HMAC secret vagy a publikus kulcs, ha a "megjegyzés" opció be van kapcsolva).
Mely algoritmusokat támogatja az aláírás-ellenőrzés?
HMAC HS256, HS384, HS512 secrettel. RSA RS256/384/512 és PS256/384/512, valamint ECDSA ES256/384/512 publikus kulccsal (PEM, SPKI). EdDSA / Ed25519 modern böngészőkben.
Miért látom, hogy "algoritmus nem támogatott"?
Bizonyos algoritmusok (pl. Ed25519) csak újabb böngészőverziókban érhetők el. Frissítse a böngészőt, vagy ellenőrizze az aláírást szerveroldalon.
Az eszköz aláír / generál is tokeneket?
Nem, ez az eszköz csak ellenőriz és dekódol. Tokenek létrehozásához használjon szerveroldali kódot jose, jjwt vagy jsonwebtoken könyvtárral.
A base64url ugyanaz, mint a normál Base64?
Majdnem. A base64url a `+` és `/` jeleket `-`-re és `_`-ra cseréli, és a paddinget (`=`) opcionálissá teszi, hogy a kódolás URL-biztos maradjon.
Mi történik, ha az `exp` már a múltban van?
A token akkor is dekódolódik (vizsgálatra), de megkapja a narancssárga "Lejárt" pillt. A szerverkódnak mindig el kell utasítania a lejárt tokeneket.
A secretem vagy a publikus kulcsom tárolódik valahol?
Csak akkor, ha bekapcsolja a "megjegyzés" opciót. Ekkor a secret és a publikus kulcs a böngésző `localStorage`-jában tárolódik, sosem szerveren. A pipa kivétele eltávolítja őket.
Milyen korlátai vannak az eszköznek?
Nincsenek rögzített korlátok. A gyakorlatban körülbelül 4 KiB alatti minden megbízhatóan működik. Nagyon nagy tokeneknél a böngésző észrevehetően lassulhat a kiemelés során.
Az összes KernelHost termék
Többre van szükséged, mint eszközökre? Nézd meg kereskedelmi tárhely-kínálatunkat.