Dekoder JWT

Co właściwie robi dekoder JWT

JSON Web Token (JWT) wygląda jak długi, nieprzejrzysty ciąg losowych znaków, ale nie jest zaszyfrowany ani tajnym szyfrem. To zwarta, przyjazna URL-om paczka przenosząca ustrukturyzowane dane między dwiema stronami. Wklej token do dekodera powyżej, a podzieli on ten ciąg i pokaże Ci prawdziwy JSON w środku — metadane, roszczenia, dla kogo token jest przeznaczony i kiedy wygasa. Wszystko dzieje się bezpośrednio w przeglądarce. Token nigdy nie jest przesyłany, logowany ani wysyłany gdziekolwiek, co ma ogromne znaczenie, gdy sprawdzanym obiektem jest aktywne poświadczenie sesji.

Trzy części, dwie kropki

Każdy poprawnie sformułowany JWT to trzy ciągi zakodowane w Base64url połączone kropkami: nagłówek.ładunek.podpis. Właśnie ten znak kropki mówi parserom, gdzie kończy się jedna sekcja i zaczyna następna, dlatego token z nieprawidłową liczbą kropek jest odrzucany, zanim w ogóle zostanie cokolwiek odczytane.

Nagłówek to mały obiekt JSON opisujący sam token. Zawiera niemal zawsze typ (typ, zwykle JWT) oraz alg — algorytm podpisywania, taki jak HS256 (HMAC z SHA-256) lub RS256 (RSA z SHA-256). Nagłówek informuje weryfikatora, w jaki sposób podpis został utworzony.

Ładunek to część, na której zależy większości osób. To kolejny obiekt JSON zawierający roszczenia — stwierdzenia o użytkowniku i tokenie. Specyfikacja dzieli roszczenia na zarejestrowane (standardowe, zarezerwowane nazwy), publiczne i prywatne (własne nazwy wymyślone na potrzeby aplikacji). Dekodowanie ładunku ujawnia, kto jest zalogowany, jaką rolę pełni i kiedy jego sesja wygasa.

Podpis to kryptograficzna pieczęć. Jest obliczany na podstawie zakodowanego nagłówka i ładunku przy użyciu algorytmu z nagłówka oraz tajnego lub prywatnego klucza. Ponieważ obejmuje obie pozostałe sekcje, każda zmiana w nagłówku lub ładunku — nawet pojedynczy znak — unieważnia go.

Roszczenia, które spotkasz najczęściej

Zarejestrowane roszczenia to krótkie, trzyliterowe nazwy zdefiniowane przez RFC 7519, dzięki czemu różne systemy mogą współdziałać. Kilka z nich pojawia się niemal wszędzie:

• iss — issuer (wystawca): kto wystawił token (Twój serwer uwierzytelniania lub dostawca tożsamości).
• sub — subject (podmiot): podmiot, którego dotyczy token, zazwyczaj stabilny identyfikator użytkownika.
• aud — audience (odbiorca): adresat, dla którego token jest przeznaczony. API powinno odrzucać tokeny, których odbiorca nie jest nim samym.
• exp — expiration time (czas wygaśnięcia): znacznik czasu Unix, po którym token nie może być akceptowany.
• iat — issued at (wystawiony o): znacznik czasu Unix z momentu utworzenia tokena.

Możesz też napotkać nbf (not before, nieważny przed) i jti (unikalny identyfikator tokena). Znaczniki czasu to sekundy od 1970 roku w UTC, dlatego dekoder renderujący je jako daty czytelne dla człowieka oszczędza Ci mentalnej arytmetyki przy sprawdzaniu, czy token już wygasł.

Dekodowanie to nie weryfikacja — to właśnie tutaj ludzie wpadają w pułapkę

To rozróżnienie jest najważniejszą rzeczą do zrozumienia w kontekście JWT. Dekodowanie oznacza odczytanie zawartości: nie wymaga klucza i każdy posiadacz tokena może to zrobić, ponieważ Base64url to kodowanie, a nie szyfrowanie. Weryfikacja oznacza udowodnienie, że token jest autentyczny i nienaruszony — przeliczenie podpisu przy użyciu poprawnego sekretu lub klucza publicznego i potwierdzenie, że się zgadza.

To narzędzie dekoduje. Pokazuje, co token mówi, a nie czy token jest godny zaufania. Token może być sfałszowany, wygasły lub powtórzony i nadal dekodować się do wyglądającego idealnie JSON-a. Nigdy nie podejmuj decyzji o autoryzacji wyłącznie na podstawie zdekodowanych roszczeń. W środowisku produkcyjnym weryfikujesz podpis po stronie serwera, sprawdzasz exp i potwierdzasz, że iss oraz aud odpowiadają oczekiwanym wartościom — używając sprawdzonej biblioteki, a nigdy ręcznie pisanego porównywania ciągów.

Ładunek to nie sejf

Ponieważ ładunek jest jedynie zakodowany w Base64url, może go odczytać każdy, kto przechwyci token. Traktuj wszystko, co się w nim znajduje, jako publiczne. Nie umieszczaj w roszczeniach JWT haseł, pełnych numerów kart kredytowych, tajnych kluczy ani żadnych wrażliwych danych osobowych — jeśli możesz zdekodować to tutaj jednym kliknięciem, to każdy inny, kto otrzyma kopię, może zrobić to samo. Podpis chroni przed modyfikacją, nigdy przed odczytaniem. Jeśli naprawdę musisz ukryć zawartość ładunku, jest to zadanie dla JWE (zaszyfrowanych tokenów) — zupełnie innej specyfikacji.

Prywatność i powiązane narzędzia

Sprawdzanie tokena to wrażliwa czynność, dlatego dekoder działa w całości po stronie klienta — przetwarzanie to zwykły JavaScript w Twojej karcie i nic nie opuszcza Twojego urządzenia. Wklejenie tokena sesji do narzędzia obsługiwanego przez serwer oznacza przekazanie aktywnego poświadczenia stronie trzeciej, czego właśnie powinieneś unikać. W kwestii leżącego u podstaw kodowania zapoznaj się z naszym narzędziem Base64 i sprawdź pozostałe narzędzia deweloperskie po więcej lokalnych narzędzi.

Najczęściej zadawane pytania