Dekoder JWT

Szczegóły

O tym narzędziu

Rozkłada token JWT na nagłówek, ładunek i podpis oraz pokazuje znaczniki czasu jako czytelne daty, żeby od razu było widać, czy token wygasł. Token nigdzie nie jest przesyłany.

JWT to trzy części zakodowane w Base64url i połączone kropkami. Nagłówek mówi, jakim algorytmem token podpisano, ładunek niesie deklaracje, a trzecia część to podpis obejmujący dwie pierwsze. Do odkodowania nie potrzeba żadnego klucza - pierwsze dwie części są zakodowane, nie zaszyfrowane - i to właśnie zaskakuje ludzi najczęściej. Każdy, kto ma token, przeczyta wszystko, co w nim jest, więc JWT nie jest miejscem na cokolwiek, czego okaziciel nie powinien zobaczyć.

Deklaracje, które warto sprawdzać, to głównie te zarejestrowane, a wszystkie są znacznikami czasu albo identyfikatorami: exp to moment wygaśnięcia, iat moment wystawienia, nbf najwcześniejsza chwila ważności, iss kto wystawił, aud dla kogo, a sub kogo dotyczy. Czasy podane są w sekundach uniksowych i dlatego wygaśnięcie wygląda jak dziesięciocyfrowa liczba, a nie data - ta strona pokazuje jedno i drugie. Token, który wygląda na zepsuty, zwykle po prostu wygasł albo trafia do odbiorcy, dla którego nie został wystawiony.

Czego odkodowanie nie powie, to czy token jest prawdziwy. Do tego trzeba klucza podpisującego i weryfikacji po stronie serwera - i to jest krok, który się liczy, bo bez niego token jest twierdzeniem, a nie dowodem. Klasyczny atak zmienia algorytm w nagłówku na „none” i usuwa podpis; biblioteka, która ufa nagłówkowi zamiast oczekiwanemu algorytmowi, taki token przyjmie.

To narzędzie wyłącznie dekoduje i robi to w całości w przeglądarce. To nie jest szczegół: JWT jest zwykle działającym poświadczeniem, a wklejenie go na stronę, która wysyła go na serwer, to oddanie komuś żywej sesji. Automatyczny test przerywa budowanie, jeśli jakiekolwiek żądanie sieciowe z tej strony zawiera token.

Warto wiedzieć

Najczęstsze pytania

Czy mój token gdzieś trafia?

Nie. Dekodowanie odbywa się w całości w przeglądarce i token nigdy nie pojawia się w żądaniu sieciowym. Pilnuje tego automatyczny test, który przerywa budowanie, gdyby jakiekolwiek żądanie z tej strony go zawierało - gwarancja warta zachodu, bo JWT to zwykle działające poświadczenie, a wklejenie go na niewłaściwą stronę równa się oddaniu sesji.

Czy narzędzie weryfikuje podpis?

Nie. Weryfikacja wymaga klucza podpisującego, a wysłanie klucza na stronę WWW byłoby gorszym pomysłem niż wysłanie samego tokenu. To narzędzie dekoduje i wyświetla; weryfikacja należy do Twojego serwera, z użyciem biblioteki i z góry ustalonego algorytmu.

Czy ładunek jest zaszyfrowany?

Nie - jest zakodowany w Base64url, co każdy odwróci bez klucza. Podpis chroni token przed zmianą, a nie przed przeczytaniem. Nigdy nie umieszczaj w JWT niczego, czego osoba go trzymająca nie powinna zobaczyć: wewnętrzne identyfikatory i role są w porządku, dane osobowe i sekrety nie.

Co znaczą exp, iat i nbf?

Wygaśnięcie, moment wystawienia i „nie wcześniej niż”, wszystkie jako znaczniki uniksowe w sekundach. exp to chwila, od której token przestaje być przyjmowany, iat moment utworzenia, a nbf najwcześniejsza chwila użycia. Ta strona pokazuje każdy z nich jako czytelną datę, bo nikt nie powinien przeliczać dziesięciocyfrowej liczby w głowie w trakcie debugowania.

Na czym polega atak „alg: none”?

Na podrobionym tokenie z algorytmem ustawionym w nagłówku na „none” i usuniętym podpisem. Weryfikator, który odczytuje algorytm z nagłówka, zamiast wymagać tego, którego się spodziewa, dojdzie do wniosku, że podpis nie był potrzebny, i token przyjmie. Zawsze ustalaj algorytm po stronie weryfikującej; porządne biblioteki domyślnie odrzucają dziś „none”, ale starszy kod i ręcznie pisane sprawdzenia nadal się na tym wykładają.