Overiť podpis JSON Web Token (JWT)

Prečo overovať podpis JWT?

JSON Web Token (JWT) sa rozkladá na tri časti oddelené bodkami: header.payload.signature. Dekódovanie JWT spočíva jednoducho v čítaní prvých dvoch častí (ktoré sú v Base64URL). Ktokoľvek to môže urobiť a ktokoľvek môže vyrobiť JWT s ľubovoľným payloadom. To, čo robí JWT dôveryhodným, je výlučne podpis: bez overenia akceptovať JWT znamená pustiť k sebe domov akúkoľvek osobu, ktorá tvrdí, že je niekým, bez požadovania občianskeho preukazu.

Tento nástroj overuje podpis JWT pomocou kľúča. Neuspokojí sa s dekódovaním: prepočítava podpis z headera, payloadu a vášho kľúča, potom ho porovnáva s podpisom tokena. Ak sa oba zhodujú, token je autentický. Inak bol vyrobený, modifikovaný alebo podpísaný iným kľúčom.

Overenie je uholným kameňom každej architektúry, ktorá používa JWT pre autentifikáciu alebo autorizáciu: bez validného podpisu môže payload klamať. Útočník, ktorý by modifikoval "role":"user" na "role":"admin", by nemal žiadne problémy to urobiť, ak by server overoval iba formát tokena a nie jeho podpis.

Bežné algoritmy

JWT špecifikácia (RFC 7518, JSON Web Algorithms) definuje viacero rodín algoritmov. Tu sú najpoužívanejšie v produkcii:

• HMAC (HS256, HS384, HS512): symetrický podpis založený na HMAC-SHA. Rovnaký secret slúži na podpisovanie a overovanie. Jednoduché na zavedenie, výkonné, ale akákoľvek strana schopná overiť token je tiež schopná ho vydať. Vhodné pre scenáre, kde sú vydavateľ a verifikátor rovnaký tím alebo rovnaký servis.
• RSA (RS256, RS384, RS512): asymetrický podpis. Privátny kľúč podpisuje, verejný kľúč overuje. Ideálne, keď sú vydavateľ a verifikátori odlišné entity (OAuth2, OpenID Connect, identity federation). Je to preferovaný algoritmus väčšiny verejných identity providerov.
• ECDSA (ES256, ES384): asymetrický podpis na eliptických krivkách. Rovnaká logika ako RSA (privátny kľúč na podpis, verejný na overenie), ale s kompaktnejšími kľúčmi a podpismi pre ekvivalentnú úroveň bezpečnosti. Stále viac rozšírený v moderných architektúrach.

Ako dodať kľúč

Formát očakávaného kľúča závisí od algoritmu deklarovaného v headeri JWT:

• HS256, HS384, HS512: kľúč je tajný reťazec (string). Je to secret zdieľaný s vydavateľom, často uložený v environment premennej ako JWT_SECRET. Žiadne zvláštne formátovanie, len surová hodnota.
• RS256, RS384, RS512: kľúč je verejný RSA kľúč vo formáte PEM, ktorý začína -----BEGIN PUBLIC KEY----- a končí -----END PUBLIC KEY-----. Zachovajte zlomy riadkov tak, ako sú, inak OpenSSL odmietne ho parsovať.
• ES256, ES384: kľúč je verejný ECDSA kľúč vo formáte PEM, na zodpovedajúcej krivke (P-256 pre ES256, P-384 pre ES384).

Príklad očakávaného RSA verejného kľúča

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxe...
...vQIDAQAB
-----END PUBLIC KEY-----

Ako funguje overovanie?

Náš server presne reprodukuje operáciu, ktorú urobil vydavateľ:

1. Rozdelí JWT na header, payload a signature.
2. Konkatenuje base64url(header) + "." + base64url(payload).
3. Pre HMAC počíta HMAC-SHA-256/384/512 s vaším secretom, potom porovnáva s prijatým podpisom cez hash_equals (constant-time porovnanie pre zabránenie timing útokom).
4. Pre RSA volá openssl_verify s vaším verejným kľúčom vo formáte PEM.

Prípady použitia

• Debug API autentifikácie: dostávate 401, overujete, či je váš token skutočne podpísaný očakávaným kľúčom.
• Validácia tokena prijatého od providera: partner (Auth0, Keycloak, Cognito, Okta) vám posiela JWT podpísané v RS256; chcete potvrdiť, že pochádzajú od neho jeho verejným kľúčom.
• Bezpečnostný audit: overiť, že tretí servis správne podpisuje svoje tokeny robustným algoritmom a nie v HS256 so slabým secretom.
• Manuálne testy: overiť, že JWT generovaný vaším kódom správne prechádza overením s poskytnutým verejným kľúčom.
• Rýchle overenie prijatého tokena: počas integrácie SSO alebo partnerského API overiť za pár sekúnd, že signature/key reťazec funguje pred napísaním akéhokoľvek riadku kódu.

Ako používať nástroj

1. Vložte kompletný JWT (tri časti oddelené bodkami).
2. Uveďte kľúč prispôsobený algoritmu headera:
   • Pre HS256, HS384 alebo HS512 je kľúč zdieľaný tajný reťazec s vydavateľom. Je to voľný reťazec, často uložený v environment premennej ako JWT_SECRET.
   • Pre RS256, RS384 alebo RS512 je kľúč verejný kľúč vo formáte PEM, ktorý začína -----BEGIN PUBLIC KEY----- a končí -----END PUBLIC KEY-----.
3. Spustite overenie. Nástroj zobrazí status (validný alebo nevalidný) a dekódovaný payload.

Bežné pasti na vyhnutie

• Algoritmus "none": spec povoľuje alg: none, čo znamená "bez podpisu". Klasická diera spočíva vo vyrobení tokena s týmto headerom v nádeji, že server ho akceptuje. Náš nástroj systematicky odmieta tokeny s alg: none.
• HMAC vs RSA zámena (algorithm confusion): útočník zmení algoritmus RS256 na HS256 a podpíše payload verejným RSA kľúčom použitým ako HMAC secret. Ak server nekontroluje algoritmus, akceptuje token. Vždy zablokujte očakávaný algoritmus na strane servera.
• HMAC secrety natvrdo v kóde: secret committed v Git repozitári robí celú dôveru tokenov kaduknou. Ukladajte secrety v environment premenných alebo aplikačnom trezore.
• Verejný kľúč vs privátny kľúč: pre overenie JWT podpísaného v RSA alebo ECDSA sa poskytuje verejný kľúč, nikdy privátny. Privátny slúži iba na podpisovanie a nesmie nikdy opustiť vydavateľa.
• Ignorovaná expirácia: validný podpis na expirovanom tokene nesmie byť nikdy akceptovaný. Pamätajte overiť exp a nbf.
• Nekontrolovaná audience: token určený API A by nemal byť akceptovaný API B. Overte claim aud.

Časové claims: exp a nbf

Okrem podpisu musí validný JWT tiež rešpektovať časové obmedzenia:

• exp (expiration): token už nie je validný po tomto dátume.
• nbf (not before): token ešte nie je validný pred týmto dátumom.

Náš nástroj explicitne signalizuje, keď je token expirovaný alebo ešte nevalidný, aj keď je jeho podpis správny. Je to dôležité: validný podpis na expirovanom tokene nesmie byť nikdy akceptovaný v produkcii.

Rozdiel od nášho JWT decodera

Náš JWT decoder sa uspokojí s dekódovaním header a payload častí pre ich učinenie čitateľnými. Nevykonáva žiadne overenie podpisu a nevyžaduje kľúč. Použite ho pre rýchlu inšpekciu obsahu tokena. Použite JWT verifier (táto stránka), akonáhle potrebujete dokázať, že je token autentický. Pre vyrobenie podpísaného JWT na testovacie účely použite náš JWT builder.

Často kladené otázky

Ukážka požiadavky

curl -X POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"...","key":"..."}'

Vstupná schéma

Koncové body

• GET https://cdrn.fr/api/v1/tools - vypíše všetky dostupné nástroje
• GET https://cdrn.fr/api/v1/tools/jwt-verifier - získa schému tohto nástroja
• POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - spustí tento nástroj s JSON payloadom