👤 Pro — bez reklamPro
// JWT → nagłówek + treść

Dekoder JWT

Wklej token JSON Web Token, aby zobaczyć, co się w nim tak naprawdę znajduje — nagłówek i treść, zdekodowane i sformatowane.

Za darmo — bez limitu użyć.

Jak zrozumieć roszczenia w środku

Gdy token jest już zdekodowany, treść (payload) to głównie garść krótkich, znormalizowanych pól zwanych roszczeniami (claims). Te, z którymi będziesz się stykać cały czas: iss nazywa wystawcę, który stworzył token, sub identyfikuje użytkownika lub podmiot, którego dotyczy, aud nazywa odbiorcę — API, dla którego jest przeznaczony — podczas gdy iat zapisuje, kiedy został wystawiony, a exp kiedy przestaje być ważny. Cokolwiek innego tam jest, jest niestandardowe: role, adresy e-mail, flagi funkcji, cokolwiek system wystawiający zdecydował się tam upakować. Roszczenia czasowe zbijają ludzi z tropu, bo są zwykłymi znacznikami czasu Unix, sekundami od 1970 roku — liczbą taką jak 1784528768, a nie czytelną datą — więc cała żywotność tokenu ukrywa się w dwóch niepozornych liczbach całkowitych.

Debugowanie odrzuconego tokenu

Gdy API odpowiada 401, a jesteś pewien, że token jest poprawny, przejdź przez krótką listę. Po pierwsze, jeśli skopiowałeś go z nagłówka Authorization, usuń słowo Bearer i spację przed nim — z nimi dołączonymi to nie jest poprawny JWT i nawet się nie zdekoduje. Następnie odczytaj exp i sprawdź, czy naprawdę jest w przyszłości: wklej tę liczbę do konwertera znaczników czasu Unix, a zobaczysz wygaśnięcie jako prawdziwą datę, często ujawniając token, który umarł godziny temu. Potem porównaj aud i iss z API, które wywołujesz — token wystawiony dla środowiska stagingowego jest rutynowo, i słusznie, odrzucany przez produkcję. I pamiętaj, że minuta rozjazdu zegarów między serwerami wystarczy, żeby świeżo wystawiony token wyglądał na jeszcze nieważny.

Tokeny, których to narzędzie nie potrafi otworzyć

Nie wszystko, co strzeże API, to czytelny JWT. Token mający pięć części oddzielonych kropkami zamiast trzech to JWE — naprawdę zaszyfrowany, a nie tylko zakodowany — i bez klucza nic czytelnego z niego nie wyjdzie, ani tutaj, ani nigdzie indziej. A wiele tokenów sesji to po prostu nieprzejrzyste losowe ciągi znaków, które od początku nigdy nie były JWT-ami; jeśli nie zaczyna się od czegoś w rodzaju eyJ, prawdopodobnie nie ma tam nic do zdekodowania. Dla tokenów, które faktycznie się otwierają, warto pamiętać, na co patrzysz: trzy bloki tekstu Base64URL sklejone kropkami. Nasze narzędzie Base64 dekoduje dowolny pojedynczy blok samodzielnie, co jest fajnym sposobem, żeby na własne oczy zobaczyć, że czytelne części JWT nigdy nie były tajne.

Co dekodowanie JWT mówi, a czego nie mówi

Nagłówek i treść tokenu JWT to po prostu JSON zakodowany w Base64URL — każdy może je zdekodować i odczytać, bez potrzeby znajomości żadnego sekretu, i to właśnie robi to narzędzie. Nie potrafi natomiast zweryfikować podpisu: wymaga to sekretu lub klucza publicznego wystawcy tokenu, których celowo nie wkleja się na przypadkową stronę internetową.

Czy to narzędzie sprawdza, czy token jest ważny i nie wygasł?

Nie — dekoduje jedynie czytelne części. Weryfikacja podpisu i sprawdzanie wygaśnięcia („exp”) odbywa się na serwerze, który wystawił token, przy użyciu sekretu, którego to narzędzie nigdy nie widzi.

Czy JWT ma być czytelny w ten sposób?

Tak — nagłówek i treść są tylko zakodowane, a nie zaszyfrowane. Nigdy nie umieszczaj sekretów ani wrażliwych danych bezpośrednio w treści JWT; podpis służy do potwierdzania, że dane nie zostały zmanipulowane, a nie do ukrywania zawartości.

Czy mój token jest gdzieś wysyłany?

Nie — dekodowanie odbywa się w całości w Twojej przeglądarce, w zwykłym języku JavaScript. Nic nie jest przesyłane.

Convertburda — uniwersalne konwersje