Dekoder tokenów JWT

Dekoder tokenów JWT

Dekoder tokenów JWT (JSON Web Token) pozwala natychmiast zdekodować każdy token JWT i odczytać jego nagłówek oraz ładunek w czytelnej postaci JSON. Narzędzie obsługuje weryfikację podpisów HMAC (HS256, HS384, HS512) i RSA (RS256, RS384, RS512) — bez instalacji bibliotek, bez backendu.

Jak działa dekodowanie i weryfikacja JWT krok po kroku

Token JWT to trzy segmenty base64url połączone kropkami: header, payload i signature. Dekoder nie wykonuje tu żadnej magii — dzieli tekst po kropkach, a następnie zamienia każdy segment z powrotem na bajty. Base64url to odmiana base64 przygotowana pod adresy URL i nagłówki HTTP: zamiast znaków + i / używa - oraz _, a znak = (padding) jest zwykle pomijany. Dlatego zwykły dekoder base64 potrafi zwrócić błąd — najpierw trzeba podmienić znaki i uzupełnić padding do wielokrotności czterech znaków.

Po dekodowaniu bajty są interpretowane jako UTF-8 i parsowane jako JSON. Widać to już na pierwszym segmencie: tokeny zaczynają się od eyJ, bo te trzy znaki base64url odpowiadają bajtom 0x7B 0x22, czyli początkowi JSON-a {". Nagłówek zawiera pole alg (algorytm podpisu) i zwykle typ, a ładunek — claimy: sub, iat, exp, iss, aud oraz pola własne aplikacji. Oba segmenty dekodowane są niezależnie, więc uszkodzony ładunek nie blokuje odczytu nagłówka.

Weryfikacja podpisu to osobny krok. Dla HMAC narzędzie liczy skrót z dokładnego łańcucha base64url(header) + "." + base64url(payload) — czyli z tych samych znaków, które są w tokenie, a nie ze zdekodowanego JSON-a: HMAC-SHA256(header.payload, sekret), po czym porównuje wynik z trzecim segmentem. Dla RSA podpis sprawdzany jest kluczem publicznym: nagłówek i ładunek trafiają do funkcji weryfikującej z funkcją skrótu SHA-256/384/512, a wynik to potwierdzenie albo odrzucenie podpisu. Każda zmiana choćby jednego znaku w pierwszych dwóch segmentach zmienia wyliczany skrót, więc sygnatura przestaje pasować.

Przykład: odczyt i weryfikacja tokenu HS256

1. Wklej w pole tekstowe token złożony z trzech segmentów. W przykładzie użyjemy nagłówka eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 i ładunku eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ, a trzeci segment to podpis.
2. Narzędzie dzieli tekst po kropkach i pokazuje rozmiary części. Nagłówek ma 36 znaków base64url, czyli 27 bajtów; ładunek ma 74 znaki, czyli 55 bajtów. Zgodność długości potwierdza, że segmenty nie zostały obcięte w schowku.
3. Odczyt nagłówka daje {"alg":"HS256","typ":"JWT"}. Pole alg wskazuje HMAC-SHA256, więc do weryfikacji potrzebny jest sekret, a nie klucz RSA.
4. Odczyt ładunku daje claimy: sub = 1234567890, name = John Doe oraz iat = 1516239022, co odpowiada 18 stycznia 2018 (UTC). W tokenie nie ma pola exp, więc narzędzie nie zgłosi ostrzeżenia o wygaśnięciu — nie znaczy to jednak, że token jest wieczny.
5. Przełącz tryb na „Weryfikuj podpis”, ustaw algorytm HS256 (albo zostaw „Automatycznie”) i wpisz sekret, którym token został podpisany.
6. Narzędzie składa łańcuch z 36 znaków nagłówka, kropki i 74 znaków ładunku (razem 111 znaków), liczy z niego HMAC-SHA256, koduje wynik base64url i porównuje go z trzecim segmentem. Zgodny sekret daje badge ważnego podpisu, a sekret różniący się choćby jednym znakiem — wynik nieprawidłowy, mimo że nagłówek i ładunek nadal dekodują się poprawnie.

Algorytmy obsługiwane przy weryfikacji — ściągawka

Praktyczne wskazówki przy czytaniu tokenów

• Zacznij od nagłówka, nie od podpisu — pole alg mówi, którego trybu weryfikacji użyć. Wpisanie sekretu HMAC do tokenu RS256 zawsze zakończy się błędem, choć token jest poprawny.
• Podawaj sekret dokładnie tak, jak w backendzie — bez cudzysłowów, bez spacji na końcu i bez zmiany kodowania. Ten sam ciąg znaków zapisany inaczej da inny skrót i wynik nieprawidłowy.
• Do RSA używaj klucza publicznego w PEM — razem z liniami BEGIN i END. Klucz prywatny nie jest potrzebny do weryfikacji i nie powinien krążyć poza serwerem podpisującym.
• Sprawdzaj komplet claimów czasowych — exp to nie wszystko: iat pozwala ustalić, kiedy token wystawiono, a brak exp w tokenie sesyjnym bywa celowy albo bywa przeoczeniem.
• Testuj weryfikację na tokenie, który znasz — zanim uznasz, że narzędzie się myli, porównaj zdekodowany alg z wybranym trybem. Najczęstsza przyczyna fałszywego błędu to niezgodność trybu z algorytmem.

Czego ta weryfikacja nie obejmuje

• Brak oceny zaufania klucza — narzędzie sprawdza tylko matematyczną zgodność podpisu z kluczem, który mu podano. Nie ustala, czy klucz pochodzi z zaufanego źródła, czy nie wygasł i czy nie został podmieniony.
• Brak kontroli unieważnienia — poprawnie podpisany token może być już odwołany po stronie serwera. Narzędzie nie sięga do list odwołań ani do stanu sesji w bazie.
• Zakres obsługiwanych algorytmów — weryfikacja obejmuje algorytmy HMAC i RSA wymienione w tabeli. Token podpisany innym algorytmem zdekodujesz i odczytasz, ale podpisu nie potwierdzisz.
• Brak reguł biznesowych — narzędzie nie wie, jakie wartości sub, aud, iss czy zakres uprawnień są oczekiwane w Twojej aplikacji. Zgodny podpis i niewygasły exp to warunek konieczny, ale nie wystarczający.

Najczęstsze pytania