Encoders & Utilities

JWT Decoder

Dekoduj nagłówek i payload JWT lokalnie w przeglądarce.

JWT token Paste a JWT — we will split it into header, payload, and signature.

O tym narzędziu

JSON Web Token (RFC 7519) to trzy segmenty kodowane Base64url połączone kropkami: header, payload i signature. JWT Decoder rozdziela token, dekoduje pierwsze dwa segmenty do JSON, formatuje je i oblicza claims związane z czasem (iat, exp, nbf) jako czytelne dla człowieka timestampy. Standardowe zarejestrowane claims (iss, sub, aud, jti) są opatrzone etykietami z ich znaczeniem. Dekodowanie działa całkowicie w Twojej przeglądarce — Twój token nigdy nie opuszcza strony.

Header mówi Ci algorytm podpisu (alg: HS256, RS256, ES256, itd.) i opcjonalny kid (key ID). Payload zawiera claims aplikacji — user ID, role, expiry. Signature jest pokazany jako blob Base64; celowo nie weryfikujemy go na tej stronie, bo weryfikacja wymaga sekretu issuera lub klucza publicznego, których nigdy nie powinno się wklejać w narzędzie trzeciej strony. Token jest traktowany wyłącznie jako dane.

Kiedy używać tego narzędzia

Odczyt tokena z własnej usługi. Zinspekuj, jakie claims faktycznie emitujesz — szybko wykryj brakujące pola, błędne audience lub zaskakujące defaulty.
Debugowanie odpowiedzi "401 Unauthorized". Sprawdź expiry, issuer, audience i scope wobec tego, czego oczekuje serwer.
Weryfikacja integracji third-party. Gdy dostawca OAuth podaje Ci token ID, zdekoduj payload, by zobaczyć, jakie user claims pakują.
Wykrywanie algorithm confusion. Jeśli alg to none lub niespodziewanie różni się między tokenami, Twoja biblioteka auth prawdopodobnie jest źle skonfigurowana.

Dlaczego nie walidujemy podpisów

Weryfikacja podpisu JWT wymaga sekretu (dla algorytmów HMAC) lub klucza publicznego issuera (dla RSA/ECDSA). Wklejenie któregokolwiek z nich do narzędzia web to błąd bezpieczeństwa — sekret skompromitowałby każdy wystawiony token; klucz publiczny, choć mniej wrażliwy, nadal może być prywatny. Dekoder potwierdza strukturę i ujawnia claims; dla prawdziwej weryfikacji użyj SDK dostarczonego z Twoją biblioteką auth (jsonwebtoken, pyjwt, jose) wewnątrz własnego kodu.

Najczęstsze pytania

Czy bezpiecznie wklejać tu mój JWT?

Dekodowanie odbywa się w całości w JavaScript w Twojej przeglądarce — żadne wywołanie sieciowe nie jest robione, żadne logowanie po stronie serwera. Mimo to JWT-y na produkcji powinny być traktowane jak credentiale: nie wklejaj długowiecznego tokena z usługi, której nie kontrolujesz, do żadnego narzędzia third-party, włącznie z naszym. Dla tokenów dev/staging lub wygasłych dekodowanie tu jest okej.

Dlaczego signature jest pokazany, ale nie zweryfikowany?

Bo weryfikacja wymaga klucza podpisującego, a wklejenie klucza podpisującego do narzędzia web byłoby poważnym błędem. Signature jest wyświetlany jako Base64, byś widział, że istnieje i ma właściwą długość dla algorytmu, ale faktyczna walidacja wobec sekretu HMAC (HS256) lub klucza publicznego (RS256/ES256) należy do wnętrza Twojej aplikacji, nie do narzędzia w przeglądarce.

Co znaczy "alg: none"?

Niepodpisany JWT. Header wprost mówi, że nie zastosowano algorytmu, więc segment signature jest pusty. alg: none istnieje w specie, ale nigdy nie powinien pojawiać się na produkcji — to źródło słynnej podatności "JWT none-algorithm", gdzie biblioteka akceptuje none jako poprawne. Jeśli widzisz to w prawdziwym tokenie z prawdziwej usługi, to poważny bug.

Czym różnią się exp, iat i nbf?

iat (issued-at) to kiedy token został utworzony. nbf (not-before) to najwcześniejszy czas, kiedy token może być użyty — zwykle równy iat, ale może być w przyszłości dla opóźnionej aktywacji. exp (expiration) to kiedy token przestaje być ważny. Wszystkie trzy to Unix timestampy w sekundach. Dobrze zachowujący się weryfikator sprawdza nbf ≤ now ≤ exp przy każdym żądaniu.