Dekoder JWT

Wklej dowolny token JWT, aby natychmiast zobaczyć jego zdekodowany nagłówek i zawartość jako sformatowany JSON.

Nasz dekoder:

• identyfikuje algorytm podpisu
• wyświetla wszystkie standardowe i niestandardowe roszczenia
• konwertuje znaczniki czasu Unix na czytelne dla człowieka daty

Wyświetlanie kodowane kolorami ułatwia odróżnienie trzech części JWT.

Debuguj problemy z JWT, sprawdzając czasy wygaśnięcia, znaczniki czasu wydania oraz wartości roszczeń.

Nasze narzędzie pokazuje, czy tokeny wygasły, ile czasu pozostało do wygaśnięcia, oraz wyróżnia potencjalne problemy.

Niezbędne do:

• tworzenia interfejsów API
• debugowania uwierzytelniania
• audytu bezpieczeństwa

JSON Web Token (JWT) to kompaktowy, bezpieczny dla adresów URL sposób reprezentowania roszczeń przekazywanych między dwoma stronami, zdefiniowany w standardzie RFC 7519 przez IETF.

JWT składa się z trzech części oddzielonych kropkami, z których każda jest zakodowana w formacie Base64URL zgodnie z RFC 4648:

• nagłówek, który deklaruje algorytm podpisu i typ tokena przy użyciu formatu JSON (RFC 8259)
• zawartość, która przenosi roszczenia — oświadczenia o podmiocie, takim jak użytkownik, oraz metadane, takie jak wygaśnięcie
• podpis, który wiąże nagłówek i zawartość razem, dzięki czemu manipulacja jest wykrywalna

Ta struktura pozwala usługom weryfikować tożsamość bez odpytywania bazy danych, dlatego tokeny JWT są powszechne w bezstanowym uwierzytelnianiu i przepływach OpenID Connect.

Aby zdekodować JWT, podziel token w miejscu dwóch kropki na trzy segmenty, a następnie zdekoduj pierwsze dwa za pomocą Base64URL.

Pierwszy segment daje JSON nagłówka, a drugi JSON zawartości, przy czym oba są czytelne jako zwykły tekst zgodnie z RFC 8259.

Base64URL (RFC 4648, sekcja 5) zastępuje '+' znakiem '-' i '/' znakiem '_' oraz pomija dopełnienie, więc standardowy dekoder Base64 może zawieść bez dostosowania. Nasze narzędzie radzi sobie z tym automatycznie i ładnie formatuje wynik.

Trzeci segment, czyli podpis, nie jest dekodowany do postaci tekstu, ponieważ jest to surowa wartość kryptograficzna.

Jak zauważają dokumenty MDN Web Docs, dekodowanie to nie weryfikacja — odczytanie zawartości nigdy nie potwierdza autentyczności tokena.

Nie — standardowy podpisany JWT (JWS) jest zakodowany, a nie zaszyfrowany, więc każdy, kto posiada token, może odczytać jego zawartość.

Kodowanie Base64URL (RFC 4648) jest odwracalne i zapewnia zerową poufność; umożliwia jedynie przesyłanie bezpieczne dla danych binarycznych. Podpis opisany w RFC 7515 (JSON Web Signature) chroni integralność i autentyczność, a nie poufność.

Jeśli musisz ukryć zawartość, użyj zamiast tego JWE (JSON Web Encryption, RFC 7516).

Zarówno OWASP, jak i IETF podkreślają to rozróżnienie: nigdy nie umieszczaj haseł, sekretów API ani danych osobowych w zawartości podpisanego JWT, ponieważ dekoder taki jak ten ujawnia każde roszczenie w czystym tekście bez żadnego klucza.

Zarejestrowane roszczenia JWT są standaryzowane przez RFC 7519, dzięki czemu różne systemy interpretują je w spójny sposób.

Zestaw główny obejmuje:

• 'iss' (wystawca)
• 'sub' (podmiot, główny adresat tokena)
• 'aud' (odbiorca, zamierzony odbiorca)
• 'exp' (czas wygaśnięcia)
• 'nbf' (nie wcześniej niż)
• 'iat' (data wydania)
• 'jti' (unikalny identyfikator tokena)

Wartości exp, nbf i iat to wartości NumericDate — sekundy od epoki Uniksa — które nasz dekoder przekształca na czytelne dla człowieka daty. Aplikacje dodają niestandardowe (prywatne) roszczenia dla ról, zakresów lub identyfikatorów dzierżawców.

Zgodnie ze specyfikacją weryfikatorzy muszą odrzucić token, którego 'exp' minęło lub którego 'aud' nie pasuje do oczekiwanego odbiorcy, co zapobiega nadużyciom między usługami.

Algorytmy podpisu JWT są zdefiniowane w RFC 7518 (JSON Web Algorithms) i identyfikowane przez wartość 'alg' nagłówka.

• Algorytmy HMAC (HS256, HS384, HS512) używają pojedynczego wspólnego sekretu zarówno do podpisywania, jak i weryfikacji, co jest proste, ale wymaga, aby każdy weryfikator posiadał ten sekret.
• Algorytmy RSA (RS256, RS384, RS512) oraz RSASSA-PSS (PS256) używają klucza prywatnego do podpisywania i klucza publicznego do weryfikacji, co jest idealne dla systemów rozproszonych i OpenID Connect.
• Algorytmy ECDSA (ES256, ES384, ES512) oferują równoważne bezpieczeństwo przy mniejszych kluczach i podpisach.

NIST publikuje leżące u ich podstaw standardy SHA-2 i ECDSA. Nasz dekoder odczytuje pole 'alg', abyś mógł potwierdzić, jakiego schematu używa token.

Tokeny JWT są powszechnie stosowane do uwierzytelniania bezstanowego, autoryzacji oraz bezpiecznej wymiany informacji w nowoczesnych interfejsach API.

Po zalogowaniu się przez użytkownika serwer generuje podpisany token JWT, który klient przesyła z powrotem w nagłówku HTTP Authorization jako token Bearer, zgodnie ze standardem RFC 6750. Ponieważ podpis jest samowystarczalny, usługi backendowe mogą zweryfikować token bez odpytywania bazy sesji, co poprawia skalowalność.

Tokeny JWT napędzają także tokeny identyfikacyjne OpenID Connect oraz wzorce tokenów dostępu OAuth 2.0.

Programiści używają dekoderów podczas debugowania, aby sprawdzić oświadczenia (claims), potwierdzić wartości odbiorcy i wystawcy oraz zweryfikować czas wygaśnięcia, gdy API zwraca błędy 401. Jak opisuje dokumentacja MDN Web Docs, ten przepływ oparty na tokenach stanowi fundament wielu architektur jednokrotnego logowania (SSO) i mikrousług.

Bezpieczne korzystanie z JWT skupia się na walidacji algorytmu, weryfikacji podpisu i egzekwowaniu czasu wygaśnięcia.

OWASP ostrzega przed klasycznym atakiem "alg: none" oraz atakami polegającymi na pomyleniu algorytmów (algorithm-confusion), w których serwer oszukany tak, że traktuje klucz publiczny RS256 jak sekret HMAC, może zostać sfałszowany; zawsze należy przypisywać oczekiwany algorytm na sztywno zamiast ufać nagłówkowi.

Kluczowe praktyki:

• Stosuj krótki czas życia 'exp' wraz z tokenami odświeżania oraz waliduj 'iss' i 'aud' przy każdym żądaniu.
• Nigdy nie przechowuj sekretów w ładunku danych (payload), ponieważ jest on jedynie zakodowany w formacie Base64.
• Przesyłaj tokeny wyłącznie za pośrednictwem protokołu HTTPS i rozważ strategie unieważniania, ponieważ standardowych tokenów JWT nie można indywidualnie unieważnić przed ich wygaśnięciem.

Przestrzeganie tych zaleceń IETF oraz OWASP pozwala wyeliminować najczęściej wykorzystywane podatności JWT.

Do najczęstszych błędów podczas pracy z tokenami JWT należą:

• Mylenie dekodowania z weryfikacją: odczytanie ładunku za pomocą dekodera niczego nie dowodzi w kwestii autentyczności, ponieważ każdy może utworzyć token niepodpisany lub sfałszowany.
• Ślepe zaufanie wartości 'alg' w nagłówku, co umożliwia ataki związane z pomyleniem algorytmów sygnalizowane przez OWASP.
• Błędna interpretacja czasu wygaśnięcia poprzez porównanie czasu w sekundach epoki ('exp') z milisekundami, przez co ważne tokeny wydają się przeterminowane.
• Używanie standardowego dekodera Base64 zamiast Base64URL (RFC 4648), co może prowadzić do uszkodzenia danych wyjściowych z powodu innego alfabetu i braku dopełnienia (paddingu).
• Umieszczanie poufnych danych w ładunku, co powoduje ich wyciek, ponieważ token jest zakodowany, a nie zaszyfrowany.

Weryfikacja podpisów po stronie serwera za pomocą oczekiwanego klucza i algorytmu pozwala uniknąć tych pułapek.

Ten dekoder JWT przetwarza tokeny w całości po stronie klienta, dzięki czemu Twój token nigdy nie opuszcza Twojego urządzenia ani nie trafia na żaden serwer.

Ponieważ podpisany token JWT jest jedynie zakodowany w formacie Base64URL (RFC 4648), jego dekodowanie nie wymaga żadnych wywołań sieciowych – nagłówek i ładunek są po prostu odwracane z postaci zakodowanej za pomocą języka JavaScript w Twojej przeglądarce.

Zachowanie operacji w środowisku lokalnym ma kluczowe znaczenie dla bezpieczeństwa: tokeny często zawierają aktywne poświadczenia sesji, a ich wklejenie do narzędzia po stronie serwera mogłoby je ujawnić w logach lub podczas przesyłania. OWASP zaleca minimalizowanie miejsc, do których podróżują poufne poświadczenia.

Dekoder działający wyłącznie w przeglądarce pozwala deweloperom na bezpieczne inspekcje tokenów produkcyjnych podczas debugowania przy zachowaniu zasad minimalnego dostępu (least-exposure), bez przekazywania danych autoryzacyjnych stronom trzecim.