Dekoder JWT

JSON Web Tokens (JWT) to kompaktowy, bezpieczny dla URL sposób reprezentowania oświadczeń między dwiema stronami. Większość JWT jest podpisywana za pomocą JWS (JSON Web Signature), co zapewnia integralność, ale nie szyfruje zawartości. To narzędzie dekoduje nagłówek i payload, aby ujawnić oświadczenia, wyświetla znaczniki czasu w czytelnym formacie i pokazuje status wygaśnięcia tokena.

Specyfikacje

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7516 - JSON Web Encryption (JWE)
• RFC 7518 - JSON Web Algorithms (JWA)
• jwt.io - JWT Debugger

Typowe zastosowania

• Debugowanie przepływów uwierzytelniania OAuth 2.0 i OpenID Connect
• Inspekcja tokenów dostępu i tokenów ID od dostawców tożsamości (Auth0, Okta, Keycloak)
• Weryfikacja, czy oświadczenia tokena odpowiadają oczekiwanym wartościom podczas rozwoju API
• Sprawdzanie wygaśnięcia tokena przy rozwiązywaniu problemów z błędami "401 Unauthorized"
• Zrozumienie struktury tokena przy integracji z usługami zewnętrznymi
• Audyt tokenów pod kątem przeglądu bezpieczeństwa (algorytm, oświadczenia, wygaśnięcie)

Funkcje

• Dekodowanie nagłówka i payloadu JWT (format JWS)
• Wyświetlanie algorytmu (HS256, RS256, ES256, PS256, EdDSA) i typu tokena
• Parsowanie zarejestrowanych oświadczeń: iss (wystawca), sub (podmiot), aud (odbiorca), exp (wygaśnięcie), nbf (nie przed), iat (wystawiony o), jti (ID JWT)
• Pokazywanie statusu wygaśnięcia z czytelnym odliczaniem
• Kopiowanie zdekodowanych sekcji jako sformatowany JSON

Przyklady

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Wskazowki

• Tokeny JWS (najczęstszy typ) są podpisane, ale nie zaszyfrowane. Każdy, kto posiada token, może odczytać payload, dekodując go z Base64.
• Tokeny JWE szyfrują payload, ale są mniej powszechne. To narzędzie dekoduje tokeny JWS.
• Zawsze weryfikuj podpisy po stronie serwera przed zaufaniem oświadczeniom. To narzędzie pokazuje zdekodowaną zawartość, ale nie weryfikuje podpisów.
• Algorytm "alg": "none" stanowi ryzyko bezpieczeństwa i powinien być odrzucany przez serwery.
• Algorytmy symetryczne (HS256) używają współdzielonego sekretu; algorytmy asymetryczne (RS256, ES256) używają par kluczy publiczny/prywatny.
• Oświadczenie "exp" to uniksowy znacznik czasu w sekundach. Sprawdź go, aby uniknąć akceptowania wygasłych tokenów.

Zrozumienie Dekoder JWT

JSON Web Tokens (JWT) to dominujący format tokenów dla nowoczesnego uwierzytelniania i autoryzacji w sieci. JWT to kompaktowy, bezpieczny dla URL ciąg składający się z trzech segmentów zakodowanych w Base64url, rozdzielonych kropkami: nagłówka określającego algorytm podpisywania, payloadu zawierającego oświadczenia o użytkowniku lub sesji i kryptograficznego podpisu zapewniającego, że token nie został sfałszowany. Ta struktura pozwala każdej stronie odczytać zawartość tokena przez proste dekodowanie Base64, podczas gdy tylko strony posiadające klucz podpisujący mogą tworzyć lub weryfikować prawidłowe tokeny.

Większość JWT używa formatu JWS (JSON Web Signature), w którym payload jest podpisany, ale nie zaszyfrowany. Pole "alg" w nagłówku określa algorytm: algorytmy symetryczne, takie jak HS256, używają współdzielonego sekretu znanego zarówno wystawcy, jak i weryfikatorowi, podczas gdy algorytmy asymetryczne, takie jak RS256 i ES256, używają klucza prywatnego do podpisywania i klucza publicznego do weryfikacji. Algorytmy asymetryczne są preferowane w systemach rozproszonych, ponieważ klucz weryfikacyjny może być udostępniany publicznie bez narażania klucza podpisującego.

Payload zawiera zarejestrowane oświadczenia zdefiniowane przez RFC 7519: "iss" (wystawca), "sub" (podmiot), "aud" (odbiorca), "exp" (czas wygaśnięcia), "nbf" (nie przed), "iat" (wystawiony o) i "jti" (ID JWT). OAuth 2.0 i OpenID Connect dodają dodatkowe oświadczenia dla zakresów, ról i informacji profilowych użytkownika. Oświadczenie "exp" jest kluczowe dla bezpieczeństwa — tokeny bez wygaśnięcia lub z nadmiernie długim czasem życia stanowią częstą podatność.

JWT są używane w tokenach dostępu OAuth 2.0, tokenach ID OpenID Connect, uwierzytelnianiu API i zarządzaniu sesjami. Dostawcy tożsamości, tacy jak Auth0, Okta i Keycloak, wydają JWT, które aplikacje weryfikują bez kontaktowania się z dostawcą, umożliwiając bezstanowe uwierzytelnianie. Jednak oznacza to również, że unieważnienie jest trudne — skompromitowany token pozostaje ważny do momentu wygaśnięcia, dlatego krótkie czasy wygaśnięcia i przepływy odświeżania tokenów są niezbędnymi praktykami bezpieczeństwa.

Ponieważ tokeny JWS są kodowane w Base64url, a nie szyfrowane, każdy, kto posiada token, może zdekodować i odczytać nagłówek oraz payload. Wrażliwe informacje, takie jak hasła, numery kart kredytowych i sekrety, nigdy nie powinny być umieszczane w payloadzie JWT. Tokeny JWE (JSON Web Encryption) szyfrują payload, ale są znacznie mniej powszechne w praktyce. Rozróżnienie między kodowaniem a szyfrowaniem jest jedną z najważniejszych rzeczy do zrozumienia podczas pracy z JWT.

Wybór algorytmu podpisywania ma istotne implikacje bezpieczeństwa. HS256 to algorytm symetryczny, który używa jednego współdzielonego sekretu zarówno do podpisywania, jak i weryfikacji, co czyni go prostym w implementacji, ale wymaga od obu stron bezpiecznego przechowywania tego samego sekretu. RS256 i ES256 to algorytmy asymetryczne, które używają klucza prywatnego do podpisywania i klucza publicznego do weryfikacji. W systemach rozproszonych preferowane są algorytmy asymetryczne, ponieważ klucz publiczny może być udostępniany otwarcie — często przez endpoint JWKS (JSON Web Key Set) — bez narażania klucza podpisującego. Opcja "alg": "none" sygnalizuje niepodpisany token bez żadnego podpisu, co oznacza, że każdy może fałszować tokeny z dowolnymi oświadczeniami. Znany atak polega na zmianie nagłówka algorytmu na "none" i usunięciu podpisu. Serwery powinny zawsze walidować algorytm wobec listy dozwolonych i odrzucać niepodpisane tokeny.

Prawidłowa obsługa wygaśnięcia jest niezbędna dla bezpieczeństwa JWT. Aplikacje powinny sprawdzać oświadczenie "exp" przy każdym żądaniu przed zaufaniem tokenowi. Gdy token wygasa, token odświeżania (przechowywany bezpiecznie, często w ciasteczku httpOnly) może być użyty do uzyskania nowego tokena dostępu bez konieczności ponownego logowania użytkownika. Utrzymywanie krótkich czasów życia tokenów dostępu — zazwyczaj 5 do 15 minut — ogranicza okno ekspozycji w przypadku skompromitowania tokena. Implementacja proaktywnego odświeżania tokenów, przed faktycznym wygaśnięciem tokena dostępu, pozwala uniknąć przerw widocznych dla użytkownika w aplikacji.