Dekoder JWT
Sprawdź nagłówek, payload i datę wygaśnięcia JWT.
O tym narzędziu
Zdekoduj JSON Web Token, aby odczytać jego nagłówek i claimy. Znaczniki czasu, takie jak exp, iat i nbf, są pokazywane jako czytelne daty, a od razu widać, czy token wygasł. Podpis nie jest weryfikowany.
Jak z tego korzystać
- Wklej JSON Web Token. Początkowe „Bearer ” jest usuwane automatycznie.
- Odczytaj zdekodowany nagłówek i payload.
- Sprawdź baner statusu i claimy czasowe, aby zobaczyć, kiedy token został wystawiony i kiedy wygasa.
Pytania
- Czy to narzędzie weryfikuje podpis?
- Nie. Narzędzie tylko dekoduje token. Weryfikacja wymaga sekretu lub klucza publicznego i powinna odbywać się na Twoim serwerze. Nigdy nie ufaj tokenowi tylko dlatego, że da się go zdekodować.
- Czy bezpiecznie jest wkleić tu prawdziwy token?
- Dekodowanie odbywa się w całości w Twojej przeglądarce, a token nigdy nie jest nigdzie wysyłany. Mimo to traktuj tokeny produkcyjne jak hasła i w miarę możliwości używaj wygasłych lub testowych.
- Co oznaczają exp, iat i nbf?
- exp to moment wygaśnięcia tokenu, iat – moment jego wystawienia, a nbf – moment, przed którym nie wolno go akceptować. Wszystkie trzy to znaczniki czasu Unix w sekundach.
- Czy każdy może odczytać zawartość JWT?
- Tak. Nagłówek i payload są tylko zakodowane w Base64url, a nie zaszyfrowane. Nie umieszczaj w payloadzie JWT sekretów ani wrażliwych danych osobowych.
- Dlaczego mój token ma pięć części zamiast trzech?
- Token z pięcioma częściami oddzielonymi kropkami to JWE, czyli zaszyfrowany JSON Web Token zdefiniowany w RFC 7516. Jego payloadu nie da się odczytać bez klucza deszyfrującego, więc ten dekoder zgłasza błąd. Token z tylko dwiema częściami został zwykle ucięty przy kopiowaniu; nawet niepodpisany token zachowuje kropkę na końcu.
- Co to jest kid w nagłówku JWT?
- kid to identyfikator klucza. Mówi weryfikującemu, którego klucza użyć, gdy wystawca publikuje kilka kluczy, np. w dokumencie JWKS. Umożliwia to rotację kluczy: nowe tokeny są podpisywane nowym kluczem, a tokeny podpisane starym pozostają ważne do czasu wygaśnięcia.
- Czy mogę edytować payload JWT i nadal go używać?
- Możesz zmienić payload i zakodować go ponownie, ale podpis przestanie pasować, więc poprawnie skonfigurowany serwer odrzuci token. Jeśli zmodyfikowany token zostanie zaakceptowany, serwer nie weryfikuje podpisów, a to poważna luka bezpieczeństwa, którą warto od razu zgłosić lub naprawić.
Co to jest JWT i jak jest zbudowany?
JSON Web Token, zdefiniowany w RFC 7519, to zwięzły ciąg złożony z trzech części oddzielonych kropkami: nagłówka, payloadu i podpisu. Nagłówek mówi, jak token jest podpisany, za pomocą wartości alg, takiej jak HS256 lub RS256. Payload zawiera claimy: kogo dotyczy token (sub), kto go wystawił (iss), dla kogo jest przeznaczony (aud) i kiedy wygasa (exp). Obie części to JSON zakodowany w base64url.
Trzecia część to podpis, obliczany z dwóch pierwszych za pomocą sekretu lub klucza prywatnego. Ponieważ nagłówek to JSON zaczynający się od nawiasu klamrowego i podwójnego cudzysłowu, prawie każdy JWT zaczyna się od eyJ – po tym rozpoznasz go w logach i nagłówkach żądań. Wklej token do tego dekodera JWT, aby zobaczyć sformatowany nagłówek i payload, z claimami czasowymi pokazanymi jako daty.
Dlaczego mój JWT jest odrzucany, choć się dekoduje?
Token, który dekoduje się bez problemu, wciąż może zostać odrzucony, zwykle z kodem 401. Najczęstszą przyczyną jest wygaśnięcie, więc sprawdź baner statusu, który mówi, czy exp jest już w przeszłości. Pamiętaj, że exp jest w sekundach: backend, który porównuje go z czasem w milisekundach z JavaScriptu, podejmie złą decyzję. Liczy się też rozjazd zegarów między serwerami, dlatego większość bibliotek dopuszcza niewielką tolerancję.
Jeśli czasy wyglądają dobrze, porównaj claimy z tym, czego oczekuje serwer. aud niezgodne z API, nieoczekiwany iss albo token od stagingowego dostawcy tożsamości wysłany na produkcję – każde z nich nie przejdzie walidacji. Weryfikacja podpisu kończy się niepowodzeniem, gdy klucz jest zły, token został zmodyfikowany albo serwer nie akceptuje alg z nagłówka. Ten dekoder nie weryfikuje podpisów, więc nie powie Ci, który z tych przypadków zachodzi.
HS256 czy RS256: jaki algorytm JWT wybrać?
HS256 podpisuje token za pomocą HMAC-SHA256 i jednego wspólnego sekretu. Każda usługa weryfikująca tokeny potrzebuje tego samego sekretu, który pozwala jej też tworzyć nowe tokeny. To w porządku przy jednym backendzie, ale ryzykowne przy wielu usługach. RS256 (RSA) i ES256 (ECDSA) używają zamiast tego pary kluczy: wystawca podpisuje kluczem prywatnym, a wszyscy pozostali weryfikują kluczem publicznym, często publikowanym w endpoincie JWKS.
Cokolwiek wybierzesz, ustal dozwolony algorytm po stronie weryfikującej, zamiast ufać polu alg w nagłówku. Token z alg ustawionym na none nie ma żadnego podpisu i zawsze musi być odrzucany. Ustawiaj krótkie exp, raczej minuty niż dni, a do dłuższych sesji używaj refresh tokenów. alg i kid odczytasz tu w panelu nagłówka, a dowolny znacznik czasu sprawdzisz w narzędziu Konwerter znaczników czasu Unix.
Coś nie działa albo wynik wygląda na błędny? Zgłoś problem z tym narzędziem