Debuger tokenów JWT (JSON Web Token) — dekoduj, sprawdzaj i łap błędy zanim zrobi to produkcja

Masz token JWT z aplikacji, logów albo nagłówka Authorization i chcesz w 10 sekund zobaczyć, co w środku naprawdę siedzi? Ten debuger rozkłada JWT na czynniki pierwsze: header, payload i sygnaturę, pokazuje daty (exp/iat/nbf), ocenia status czasowy i — jeśli chcesz — weryfikuje podpis dla HSxxx lub RSxxx.

JWT to wygodny standard, ale też klasyczny generator „cichych problemów”: token niby wygląda poprawnie, a logowanie nie działa, API krzyczy 401, uprawnienia się rozjeżdżają albo data wygaśnięcia jest ustawiona w kosmos. Debuger tokenów JWT jest od tego, żebyś nie zgadywał. Wklejasz token, klikasz „Dekoduj” i od razu widzisz strukturę, metadane i potencjalne miny.

Jak użyć debugera JWT krok po kroku (bez filozofii)

Najczęściej to wygląda tak: dostajesz token w nagłówku, w ciasteczku albo w logach i chcesz „zobaczyć prawdę”. Zrób to w tej kolejności — działa zarówno dla tokenów od Twojego backendu, jak i tych z zewnętrznych providerów.

1. Wklej token JWT do pola (musi mieć 3 części oddzielone kropkami).
2. Kliknij „Dekoduj Token” i przejrzyj header + payload w JSON.
3. Sprawdź status czasu: czy token nie wygasł i czy nbf nie blokuje go jeszcze „przed startem”.
4. Jeśli to problem z zaufaniem tokena: zaznacz „Weryfikuj sygnaturę” i podaj secret (HS) albo klucz publiczny (RS).
5. Rzuć okiem na audyt bezpieczeństwa — czasem narzędzie od razu podpowiada, co jest podejrzane.

Co właściwie siedzi w JWT i na co patrzeć najpierw

JWT składa się z trzech elementów: header, payload i signature. Header mówi, jak token jest podpisany (np. alg), payload niesie dane (claimy), a podpis ma gwarantować, że treść nie została zmieniona.

Header: alg, typ i czasem tajemnicze kid

Najważniejsze pole to alg — algorytm podpisu. Jeśli widzisz tam none, to zapala się czerwona lampka: taki token nie powinien być akceptowany w żadnym poważnym scenariuszu. Pole typ zwykle jest „JWT”, a kid bywa używane do wskazania konkretnego klucza (np. w środowiskach z rotacją kluczy).

Payload: claimy, role, identyfikatory i „czas”

W payload często są identyfikatory użytkownika, nazwy ról, uprawnienia, a także standardowe claimy typu exp, iat, nbf. Debuger pokaże je w JSON i od razu przeliczy na czytelną datę, dzięki czemu nie musisz ręcznie przeliczać timestampów.

Najczęstsze scenariusze: po czym poznasz, że token „udaje” poprawny

Algorytmy JWT w praktyce: co wymaga secretu, co klucza, a co jest podejrzane

Mini-checklista: co sprawdzić zanim uznasz token za „wadliwy”

Czasem token jest OK, tylko kontekst po stronie aplikacji jest inny niż myślisz. Ta checklista oszczędza sporo nerwów.

• Czy JWT ma dokładnie 3 części oddzielone kropkami (header.payload.signature)?
• Czy exp nie jest w przeszłości i czy serwery mają zsynchronizowany czas?
• Czy nbf nie blokuje tokena „jeszcze przed startem”?
• Czy alg w headerze zgadza się z tym, czego oczekuje backend?
• Czy weryfikacja sygnatury przechodzi na właściwym secrecie/kluczu publicznym?
• Czy payload nie zawiera danych, których nie powinno być w tokenie (np. wrażliwych)?

Bezpieczeństwo JWT bez straszenia: na co ten debuger zwraca uwagę

Narzędzie nie udaje pełnego skanera bezpieczeństwa, ale potrafi wyłapać rzeczy, które w realnych projektach robią różnicę. Przykładowo: algorytm none to czerwony alarm. Do tego dochodzą praktyczne ostrzeżenia dla HMAC, gdy sekret jest podejrzanie krótki — bo brute force lub wycieki konfiguracji zdarzają się częściej, niż byśmy chcieli.

Najważniejsze jest podejście: dekodowanie to podgląd, weryfikacja to zaufanie. Jeśli chcesz być pewny, że token nie został podmieniony, zawsze korzystaj z opcji weryfikacji podpisu.

FAQ — pytania, które pojawiają się zawsze

Jeśli chcesz: użyj debugera teraz

Wklej token, dekoduj i zobacz, co w nim siedzi. A jeśli sprawa dotyczy bezpieczeństwa lub integracji — odpal weryfikację podpisu i miej temat zamknięty na faktach, nie domysłach.