Aláírt JSON Web Token (JWT) létrehozása

Mi az a JWT Builder?

A JWT Builder egy online eszköz, amely egy aláírt JSON Web Tokent (JWT) állít elő JSON payloadból és egy HMAC titokból. Azoknak a fejlesztőknek szól, akiknek gyorsan teszt tokent kell generálniuk egy API viselkedésének ellenőrzéséhez, egy hitelesített munkamenet szimulálásához a Postmanben, vagy egy lejárattal vagy token hatókörrel kapcsolatos hiba reprodukálásához.

Szemben a JWT decoder eszközünkkel, amely csak a meglévő tokent olvassa be, a JWT Builder teljes tokent készít: felépíti a fejlécet, kódolja a payloadot, kiszámítja a HMAC aláírást, és mindent összeállít a piaci JWT könyvtárak által elvárt header.payload.signature kompakt formátumba.

Miért generáljunk JWT-t?

A JWT builder nem éles tokenek kibocsátására szolgál. Ez elsősorban fejlesztési és tesztelési eszköz. Íme a leggyakoribb forgatókönyvek:

• Integrációs tesztek: kiszámítható JWT-k előállítása a védett végpontokat érintő E2E tesztek irányításához, anélkül, hogy a valódi identitásszolgáltatótól függne.
• API mockok: az IdP hívás ideiglenes helyettesítése ugyanazzal a teszt titokkal helyben aláírt JWT-vel.
• Helyi fejlesztés: csatlakozás saját backendhez a kívánt claim-eket tartalmazó token kézi generálásával, a teljes OAuth2 folyamat végigvitele nélkül.
• Demók: hitelesítési útvonal vagy engedélyalapú munkafolyamat illusztrálása anélkül, hogy valódi IdP lenne kéznél.
• Hibák reprodukálása: lejárt token, helytelen aud értékű token, bizonyos claim-ek nélküli token hamisítása az API hibaútvonalainak teszteléséhez.
• Egyéni parser hibakeresése: speciálisan összeállított JWT-k bevitele egy saját készítésű parser teszteléséhez.

Egy JWT összetétele

Az aláírt JWT három, ponttal elválasztott szegmensből áll, amelyek mindegyike Base64URL kódolású (a Base64 változata padding nélkül, és -/_ karakterekkel a +// helyett):

• Header (fejléc): egy JSON objektum, amely leírja az aláíró algoritmust és a token típusát, például {"alg":"HS256","typ":"JWT"}. A JWT Builder automatikusan generálja a választott algoritmus alapján.
• Payload: tetszőleges JSON objektum, amely a token claimjeit tartalmazza (alany, engedélyek, lejárati dátumok). Ezt Ön adja meg.
• Signature (aláírás): egy HMAC-SHA, amelyet a base64url(header) + "." + base64url(payload) összefűzéséből számítanak ki az Ön titkos kulcsával. Ez garantálja a token integritását.

Felhasználási esetek részletesen

• API mock E2E tesztekhez: a Cypress vagy Playwright szvitnek egy Authorization: Bearer ... fejlécet megkövetelő API-t kell hívnia. Ahelyett, hogy minden tesztnél teljes bejelentkezést vezényelnénk le, röptében aláírunk egy JWT-t a megosztott titokkal, és beillesztjük a fejlécbe.
• SSO demó: föderált hitelesítési útvonal bemutatása online IdP-től való függés nélkül.
• Teszt fixture: determinisztikus JWT generálása ismert payloadból, hogy stabil fixture-ként szolgáljon az egységtesztekben.
• Egyéni parser diagnózisa: saját JWT parser tesztelése szándékosan minimális vagy szándékosan furcsa tokenekkel (hiányzó claim-ek, váratlan típusok).
• Tanulás: konkrétan megérteni, hogyan épül fel egy JWT, a payload módosításával és az aláírás változásának megfigyelésével.

Támogatott algoritmusok: HS256, HS384, HS512

Eszközünk támogatja a JWT specifikáció (RFC 7519) három szabványos HMAC algoritmusát:

• HS256: HMAC SHA-256-tal. 32 bájtos aláírás. A gyakorlatban a leggyakrabban használt, jó kompromisszum a sebesség és a kriptográfiai szilárdság között. Alapértelmezés szerint ajánlott.
• HS384: HMAC SHA-384-gyel. 48 bájtos aláírás. Olyan kontextusokhoz alkalmas, amelyek nagyobb biztonsági margót igényelnek.
• HS512: HMAC SHA-512-vel. 64 bájtos aláírás. A legrobusztusabb, egy kissé nagyobb token árán.

HMAC vagy RSA?

A HS* algoritmusok szimmetrikusak: ugyanaz a kulcs szolgál az aláíráshoz és az ellenőrzéshez. Ez egyszerű és gyors, de azt jelenti, hogy minden olyan szolgáltatás, amely képes ellenőrizni a tokent, képes kibocsátani is azt. Ha szét kell választania ezt a két szerepkört (egyetlen kibocsátó, több fogyasztó), forduljon az RS256/RS384/RS512 (RSA, aszimmetrikus) algoritmusokhoz, amelyeket JWT verifier eszközünkkel ellenőrizhet.

Biztonság: a titok védelme

A HMAC-al aláírt JWT biztonsága teljes egészében a titok bizalmasságán alapul. Néhány alapszabály:

• Használjon hosszú és véletlenszerű titkot. Az RFC 7518 legalább az algoritmus kimeneti méretét ajánlja (32 bájt a HS256-hoz, 48 a HS384-hez, 64 a HS512-höz). Egy emberi jelszó, mint az azerty123, triviálisan támadható offline brute force módszerrel.
• Soha ne írjon alá JWT-t ügyféloldalon. A titok a böngészőnek terjesztett JavaScript kódban kötne ki, minden felhasználó számára láthatóan. Az aláírásnak mindig a szerveroldalon kell maradnia.
• Tárolja a titkot környezeti változóban (pl. JWT_SECRET), soha ne Git tárolóban. Fontolja meg egy széf használatát, mint például a HashiCorp Vault, az AWS Secrets Manager vagy a Symfony Secrets a stacktől függően.
• Rendszeresen forgassa a titkot (key rotation), különösen minden incidens vagy a konfigurációhoz hozzáféréssel rendelkező személy távozása után.
• A JWT Builder tesztelésre és tanulásra szolgál. Éles használathoz használja keretrendszerének JWT könyvtárát (lcobucci/jwt, firebase/php-jwt, jose-php).

Jó gyakorlatok a claim-ekhez

A payload egy szabad JSON objektum, de az RFC 7519 meghatároz egy sor bejegyzett claim-et (registered claims), amelyeket a JWT könyvtárak tudnak értelmezni. A megfelelő claim-ek beillesztése hordozhatóvá teszi a tokent, és elkerüli a finom hibákat:

• iss (issuer): a kibocsátó azonosítója, például "https://api.pelda.hu".
• sub (subject): az érintett személy vagy entitás azonosítója, gyakran a felhasználói azonosító.
• aud (audience): kinek szól a token, megakadályozva a token újrafelhasználását egy másik API-n.
• exp (expiration time): Unix időbélyeg, amely után a token már nem érvényes. Mindig illessze be, még teszt token esetén is: a lejárati idő nélküli token rossz szokás, amelyet később nehéz kijavítani.
• nbf (not before): időbélyeg, amely előtt a token még nem érvényes. Hasznos egy később aktiválható token előzetes kibocsátásához.
• iat (issued at): kibocsátási időbélyeg, hasznos a naplózáshoz és a visszavonáshoz.
• jti (JWT ID): a token egyedi azonosítója, elengedhetetlen az idempotenciához és a visszavonási lista megvalósításához.

Példa tipikus payloadra

{
  "iss": "https://api.pelda.hu",
  "sub": "user-12345",
  "aud": "mobile-app",
  "iat": 1714723200,
  "exp": 1714726800,


    
Hogyan kell használni az eszközt
    

    
Adja meg a payloadot érvényes JSON formátumban. Ez egy objektum, tehát { jellel kezdődik és } jellel végződik.
    
Adja meg a HMAC titkot. Válasszon egy hosszú és véletlenszerű karakterláncot a produkciós tokenekhez.
    
Válassza ki az algoritmust: alapértelmezés szerint HS256, igény szerint HS384 vagy HS512.
    
Kattintson a létrehozás gombra. Megjelenik az aláírt JWT, amely készen áll a beillesztésre egy Authorization: Bearer ... fejlécbe.
    
Ezt követően ellenőrizheti a tokent ugyanazzal a titokkal a round-trip konzisztenciájának megerősítéséhez, vagy dekódolhatja a tartalom újraolvasásához.



    
Gyakran ismételt kérdések
    

    
Melyik algoritmust válasszam: HS256, HS384 vagy HS512?
    

        Szinte minden esetben a HS256 a helyes választás. Tökéletesen elegendő biztonsági szintet nyújt az autentikációs tokenekhez, kompakt aláírással (32 bájt) és gyors számítással. A HS384 és a HS512 csak konkrét szabályozási környezetben vagy nagyon hosszú élettartamú tokenek kezelése esetén indokolt. A nagyobb aláírásméret minden HTTP kérést elnehezít.
    


    
Hogyan generálhatok RSA párt a JWT-jeim aláírásához?
    

        OpenSSL-lel két paranccsal: openssl genrsa -out private.pem 2048 a privát kulcshoz, majd openssl rsa -in private.pem -pubout -out public.pem a publikus kulcs kinyeréséhez. Új szolgáltatásokhoz ma már 3072 bites vagy 4096 bites kulcsokat javasolunk. A privát kulcs a kibocsátó oldalon marad; a publikus kulcs szabadon terjeszthető a tokeneket ellenőrizni hivatott szolgáltatásoknak.
    


    
Mi az ajánlott lejárati idő?
    

        Access token esetén: 5-15 perc. Refresh token esetén: néhány naptól néhány hétig, de szerveroldali visszavonási mechanizmussal kiegészítve. Minél hosszabb élettartamú a token, annál nagyobb a visszaélési lehetőség szivárgás esetén. Teszt JWT-khez választhat bőkezűbb időtartamot, de kerülje a több éves exp értéket: ezek gyakran véletlenül Git tárolókba kerülnek.
    


    
Aláírhatom a tokent egy nagyon rövid titkos kulccsal?
    

        Technikailag igen, de erősen ellenjavallt. Egy 16 bájtnál rövidebb HMAC titok gyengén ellenálló az offline brute force támadásokkal szemben, és léteznek olyan eszközök, amelyek egy gyenge titokkal rendelkező HS256 JWT-t másodpercek alatt feltörnek. Az RFC 7518 legalább az algoritmus kimeneti méretét javasolja: 32 bájt a HS256, 48 a HS384 és 64 a HS512 esetén. Generálja titkait az openssl rand -base64 64 paranccsal.
    


    
Miért utasítják el a payloadomat?
    

        A payloadnak érvényes JSON objektumnak kell lennie. Gyakori hibák: egyszeres idézőjelek használata kettős helyett, felesleges vessző a } előtt, vagy idézőjelek nélküli érték egy karakterláncnál. Először ellenőrizze a JSON-t a JSON formázónkkal.
    


    
A generált JWT-t más is megfejtheti?
    

        Egy aláírt JWT nincs titkosítva: a payload csupán Base64URL kódolású. Bárki elolvashatja. Ha a payload érzékeny adatokat tartalmaz, használja a JWE (JSON Web Encryption) formátumot, amely titkosítást is ad hozzá. Eszközünk JWS-t (csak aláírtat) állít elő.