JWT (JSON Web Token) to otwarty standard zdefiniowany przez IETF w RFC 7519 (RFC 7515 opisuje formę podpisywania JWS, RFC 7516 opisuje szyfrowanie JWE, RFC 7517 definiuje klucze JWK) do bezpiecznego przesyłania 'oświadczonych' informacji o użytkowniku między żądaniami HTTP, przepływami OIDC i wywołaniami mikrousług. Standardowy ciąg JWT składa się z trzech segmentów zakodowanych Base64URL: Header (algorytm i typ), Payload (Claims, dane użytkownika) i Signature (podpis oparty na kluczu nad pierwszymi dwoma). Trzy segmenty są połączone kropką `.`, np. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT nie jest szyfrowaniem.** To najczęstsze nieporozumienie. Payload jest domyślnie jawnym tekstem — każdy może go zdekodować Base64URL i odczytać zawartość. JWT zapewnia **wykrywanie naruszeń**, nie poufność: serwer ponownie podpisuje Header.Payload wspólnym kluczem i porównuje z Signature tokena. Jeśli się zgadzają, token nie został zmieniony podczas transportu. To metafora 'biletu kolejowego z antyfałszywowym stemplem': inspektor pyta, czy bilet jest prawdziwy, nie czy kod QR jest nieczytelny.
JWT ładnie dzieli odpowiedzialności między 13 algorytmów. **Rodzina HMAC** (HS256/HS384/HS512) używa symetrycznego klucza do podpisywania i weryfikacji, szybka i prosta, odpowiednia dla pojedynczej usługi lub zaufanego klastra; sekret musi mieć co najmniej długość skrótu (np. ≥ 32 bajty dla HS256). **Rodzina RSA** (RS256/RS384/RS512) używa RSASSA-PKCS1-v1_5, najczęstszego schematu asymetrycznego — sygnatariusze mają klucz prywatny, weryfikatorzy mają klucz publiczny. **Rodzina RSA-PSS** (PS256/PS384/PS512) używa nowszego wypełnienia RSA-PSS z silniejszymi gwarancjami bezpieczeństwa, preferowana przez AWS SigV4 i nowoczesnych dostawców tożsamości OIDC. **Rodzina ECDSA** (ES256/ES384/ES512) używa krzywych eliptycznych (odpowiednio P-256/P-384/P-521) z krótszymi podpisami i lepszą wydajnością. **EdDSA** (głównie Ed25519) jest niezwykle szybka i deterministyczna (ten sam komunikat + ten sam klucz = ten sam podpis za każdym razem) i jest zalecanym algorytmem w OAuth 2.1 i nowych protokołach.
Bezpieczeństwo to miejsce, gdzie JWT potyka się w produkcji. OWASP JWT Cheat Sheet wymienia co najmniej cztery twarde zasady: (1) nigdy nie umieszczaj haseł, krajowych dowodów osobistych, numerów kart lub kluczy API jako jawnego tekstu w Payload; (2) serwer musi **nigdy nie ufać polu alg** zadeklarowanemu w Header Tokena — musi weryfikować z zakodowanym na sztywno algorytmem, w przeciwnym razie atakujący przepisujący nagłówek do `alg: none` omija wszystko (to jest źródło historycznych CVE, takich jak CVE-2015-9235); (3) sekrety HMAC muszą być losowe i mieć co najmniej 32 bajty, nigdy krótkie ciągi; (4) weryfikacja to więcej niż tylko sprawdzanie podpisów — musisz także walidować `exp` (wygaśnięcie), `nbf` (not-before), `iss` (wydawca) i `aud` (odbiorca). To narzędzie podświetla każdy z tych Claims w UI, abyś mógł natychmiast zobaczyć, czy awaria to problem podpisu, problem czasu czy problem Claims.
JWT nie jest zamiennikiem sesji. Sesje przechowują stan użytkownika na serwerze (Redis lub baza danych); JWT pakuje stan do tokena. Architektury mikrousług, bezstanowe API, klienci mobilni i konfiguracje z dużą liczbą CORS korzystają z JWT; tradycyjne systemy korporacyjne i przepływy wymagające natychmiastowego odwołania (np. 'wyrzuć tego użytkownika teraz') są nadal lepiej obsługiwane przez sesje. To narzędzie obejmuje zarówno czyste debugowanie JWT, jak i kroki parsowania Tokena / weryfikacji podpisu / edycji Payload migracji z sesji do JWT.