JWT Decoder - Dekoder Tokenu JWT i Weryfikacja Podpisu

Token JWT przed dekodowaniem i po nim

Ciąg zaczynający się od eyJ z dwiema kropkami to prawie zawsze JWT, czyli JSON Web Token. Dekoder rozdziela go na nagłówek, payload i podpis, zamienia base64url z powrotem na czytelny JSON, tłumaczy daty exp, iat i nbf na czas polski i mówi, czy token jeszcze jest ważny. Po wpisaniu sekretu sprawdza też podpis HS256, HS384 albo HS512.

Bez dekodera

długi ciąg znaków, z którego nie widać, kto go wystawił i dla kogo
data wygaśnięcia jako liczba w rodzaju 1700003600
nie wiadomo, czy błąd 401 to wygasły token, czy zły podpis
łatwo przeoczyć "alg": "none" albo za krótki sekret

Z dekoderem

nagłówek i payload jako sformatowany JSON
każda data w czasie polskim, w UTC i jako „za 1 h” lub „2 dni temu”
osobno stan podpisu i stan ważności
ostrzeżenia oparte na RFC 7519 i RFC 7518

Token - wklej cały, może być z przedrostkiem Bearer skopiowanym z nagłówka Authorization.
Sekret - tylko dla HS256, HS384 i HS512. Puste pole = samo dekodowanie.
Format sekretu - zwykły tekst albo base64url, jeśli aplikacja dekoduje klucz z Base64 do bajtów (tak jak pole k w kluczu JWK, RFC 7518).
Sprawdź na chwilę - puste pole = teraz. Inna data pokazuje, czy token był ważny w momencie błędu z logu.

Z czego składa się token i jak liczony jest podpis

JWT = BASE64URL(nagłówek) . BASE64URL(payload) . BASE64URL(podpis)

podpis HS256 = HMAC-SHA256(sekret, "BASE64URL(nagłówek).BASE64URL(payload)")

Base64url to Base64 z dwoma znakami zamienionymi na bezpieczne w adresie: - zamiast + i _ zamiast / (RFC 4648, sekcja 5). RFC 7515 każe dodatkowo usunąć końcowe znaki =. Podpisywany jest dokładnie tekst dwóch pierwszych części z kropką, a nie sformatowany JSON, więc zmiana jednej spacji w payloadzie daje inny podpis.

Obliczenie 1: dekodowanie nagłówka. Pierwsza część eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 to po zdekodowaniu {"alg":"HS256","typ":"JWT"}. Stąd bierze się charakterystyczny początek eyJ: tak w base64url zaczyna się obiekt JSON, którego pierwszy klucz zaczyna się od litery.

Obliczenie 2: daty w payloadzie. Payload {"sub":"42","name":"Anna","iat":1700000000,"exp":1700003600} ma exp - iat = 3 600 sekund, więc token żyje 1 godzinę. Obie wartości to NumericDate, czyli sekundy od 1 stycznia 1970 UTC (RFC 7519); dekoder zamienia je na datę i godzinę w czasie polskim.

Obliczenie 3: podpis. Ten sam token z sekretem tajny-klucz-testowy-o-dlugosci-32B! (35 bajtów) ma podpis Vdpa3BoQqFgR6SmAZ-klGiOSg6x-Po0b5FUftEdbWTQ i dekoder pokazuje „poprawny”. Zmiana ostatniego znaku sekretu na ? daje 5BDVFifCkjC5bqwYHnA11l9gxU4MFJPeOfSkWW3ud_8, czyli „NIEPOPRAWNY”, a obok podpis policzony z wpisanym sekretem do porównania.

Co zyskujesz przy typowych problemach z tokenem

Najczęstsze sytuacje przy debugowaniu logowania i API. Środkowa kolumna to to, co widać bez narzędzia, prawa to odpowiedź z wyniku dekodera.

Sytuacja	Bez dekodera	Z dekoderem
API zwraca 401	sam kod błędu	„wygasł 12 min temu” albo „podpis NIEPOPRAWNY”
Token działa u jednych, u innych nie	zgadywanie	pole `aud` z listą odbiorców i `iss` wydawcy
„Token jeszcze nieważny”	liczba w `nbf`	data „ważny od” i ostrzeżenie o `iat` w przyszłości (rozjechany zegar)
Data wygaśnięcia za kilkadziesiąt tysięcy lat	dziwna liczba	„wygląda na milisekundy”, bo NumericDate to sekundy
Podpis nie przechodzi mimo dobrego sekretu	brak wskazówki	przełącz format sekretu: base64url, jeśli aplikacja dekoduje klucz z Base64, inaczej zwykły tekst
Przegląd bezpieczeństwa	trzeba czytać kod	ostrzeżenie o `alg: none`, braku `exp` i sekrecie krótszym niż wymaga RFC 7518

Tabela referencyjna: claimy i algorytmy

Zarejestrowane pola payloadu z RFC 7519 (sekcja 4.1) i algorytmy z RFC 7518 (sekcja 3.1). Wszystkie pola są opcjonalne; o tym, które są wymagane, decyduje aplikacja.

Pole	Nazwa w RFC	Co zawiera
`iss`	Issuer	kto wystawił token
`sub`	Subject	kogo dotyczy, zwykle identyfikator użytkownika
`aud`	Audience	odbiorca albo lista odbiorców; serwer spoza listy musi odrzucić token
`exp`	Expiration Time	od tej chwili token jest nieważny
`nbf`	Not Before	wcześniej token jest nieważny
`iat`	Issued At	kiedy wystawiono, pozwala policzyć wiek tokenu
`jti`	JWT ID	unikalny identyfikator, np. do blokowania użytych tokenów

alg	Podpis	RFC 7518	Sprawdzisz tutaj
`HS256`	HMAC z SHA-256, klucz min. 256 bitów	Required	tak, sekretem
`HS384` / `HS512`	HMAC z SHA-384 / SHA-512, klucz min. 384 / 512 bitów	Optional	tak, sekretem
`RS256`	RSA PKCS#1 v1.5 z SHA-256	Recommended	tylko dekodowanie
`ES256`	ECDSA na krzywej P-256	Recommended+	tylko dekodowanie
`none`	bez podpisu	Optional	ostrzeżenie: nie przyjmuj takiego tokenu

Często pytacie o JWT

JWT co to jest, krótko?

Podpisana „przepustka” w formacie JSON: serwer logowania wpisuje do niej, kim jesteś i do kiedy, a inne serwery sprawdzają tylko podpis, bez pytania bazy. Format opisuje RFC 7519.

Czy dekodowanie tokenu to złamanie zabezpieczeń?

Nie. Base64url to tylko zapis, nie szyfrowanie, więc payload przeczyta każdy, kto ma token. Zabezpieczeniem jest podpis: bez sekretu nie da się zmienić treści tak, żeby serwer to przyjął. Dlatego w payloadzie nie trzyma się haseł ani danych wrażliwych.

Czy mogę wkleić token z produkcji?

Nie wklejaj tokenów, które jeszcze działają. Ważny token to klucz do konta, a obliczenie wykonuje serwer LiczGrupa.pl i dane wejściowe trafiają do dziennika obliczeń. Bezpiecznie: token testowy, wygasły albo z usuniętym podpisem. To samo dotyczy sekretu; przy testach weź losowy, np. z generatora haseł.

Token ma 5 części zamiast 3. Co to jest?

Token zaszyfrowany, JWE (RFC 7516): nagłówek, zaszyfrowany klucz, wektor IV, szyfrogram i znacznik uwierzytelnienia. Dekoder pokaże nagłówek z algorytmem i metodą szyfrowania, ale treść da się odczytać tylko kluczem odbiorcy.

Serwer odrzuca token, który wygasł kilka sekund temu, a inny jeszcze go przyjmuje. Dlaczego?

RFC 7519 pozwala na „small leeway”, zwykle do kilku minut, na rozjazd zegarów. Każda biblioteka ustawia tę tolerancję po swojemu, więc granica wygaśnięcia nie jest co do sekundy taka sama wszędzie.

Jak sprawdzić podpis RS256?

Potrzebny jest klucz publiczny wydawcy, zwykle publikowany jako zestaw JWKS pod adresem z konfiguracji OpenID. Dekoder pokazuje identyfikator klucza kid z nagłówka, po którym wybiera się właściwy klucz, a samą weryfikację robi biblioteka JWT w aplikacji.