Dekoder JWT
Działa w całości w Twojej przeglądarce. Twoje pliki i dane nigdy nie opuszczają Twojego urządzenia.
- iat: 2018-01-18T01:30:22.000Z
O tym narzędziu
JSON Web Token to trzy segmenty zakodowane w Base64Url, oddzielone kropkami: nagłówek opisujący algorytm podpisu, payload z claimami i podpis. Nagłówek i payload są tylko zakodowane, nie zaszyfrowane, więc każdy, kto ma token, może je odczytać. To narzędzie dekoduje oba od razu. Format definiuje RFC 7519.
Co widzę po wklejeniu tokena?
Po wklejeniu tokena zobaczysz jego nagłówek i payload jako sformatowany JSON, a do tego prostym językiem opisany każdy claim związany z czasem. Nagłówek zwykle podaje algorytm podpisu (alg) i typ tokena. Payload zawiera to, co umieścił tam wystawca: standardowe claimy jak wystawca (iss), podmiot (sub), odbiorca (aud), czas wygaśnięcia (exp), czas wystawienia (iat), ważny od (nbf), a do tego dowolne własne claimy dodane przez dostawcę, na przykład role czy scope’y. Dla exp, iat i nbf narzędzie dodatkowo zamienia znacznik czasu Unix na czytelną datę i mówi, czy token już wygasł albo jeszcze nie jest ważny, co zwykle jest najszybszym sposobem na sprawdzenie, dlaczego API odrzuciło token. Żeby token dał się zdekodować, potrzebuje dokładnie trzech części oddzielonych kropkami, a pierwsze dwie muszą zawierać poprawny JSON zakodowany w Base64Url; wszystko inne narzędzie zgłosi jako nieprawidłowy JWT.
Czy mój token jest gdzieś wysyłany?
Nie. Dekodowanie odbywa się wyłącznie w przeglądarce: token jest parsowany i rozkładany lokalnie, nic nie trafia do sieci. Dzięki temu można tu bezpiecznie wklejać prawdziwe tokeny dostępu, także z systemu produkcyjnego, bez obawy, że przejdą przez zewnętrzny serwis.
Czy narzędzie weryfikuje podpis?
Nie, i to ważna różnica. Narzędzie dekoduje wyłącznie nagłówek i payload, czyli po prostu odkodowuje Base64Url i parsuje wynik jako JSON. Nie sprawdza podpisu, więc nie potrafi powiedzieć, czy token jest autentyczny, ani czy ktoś go zmodyfikował. Dekodowanie pokazuje, co token deklaruje; weryfikacja dowodzi, że te deklaracje są prawdziwe, a taka kontrola musi odbyć się względem klucza podpisującego wystawcy, zwykle na serwerze albo w bibliotece backendowej, która ma do niego dostęp. Przy debugowaniu odrzuconego tokena dekodowanie tutaj szybko pokazuje, czy claimy wyglądają sensownie, ale poprawne zdekodowanie to nie to samo co ważny podpis.
Więcej o tym, jak trzy segmenty łączą się w całość i co oznaczają poszczególne standardowe claimy, wyjaśnia wprowadzenie do JWT od Auth0, obok samego RFC.