Dekoduj JWT Online
Dekoduj tokeny JWT w przeglądarce — żadne dane nie są wysyłane na serwer.
Dlaczego warto
Debuguj tokeny JWT natychmiastowo
100% prywatne
Dekodowanie odbywa się w przeglądarce. Twój token nigdy nie opuszcza Twojego urządzenia.
Natychmiastowe
Dekodowanie w czasie rzeczywistym podczas pisania. Bez przycisków, bez czekania.
Sformatowany JSON
Nagłówek i payload wyświetlane jako czytelny JSON z podświetlaniem składni.
Obsługuje wszystkie typy JWT
Działa z HS256, RS256, ES256 i każdym algorytmem ze standardu JOSE.
Jak to działa
Trzy kroki, żadnych komplikacji
Wklej swój token JWT
Skopiuj i wklej dowolny JWT do pola wejściowego. Format to trzy części oddzielone kropką: header.payload.signature.
Natychmiastowe dekodowanie
Nagłówek i payload są dekodowane z Base64URL i wyświetlane jako sformatowany JSON. Sprawdź typ algorytmu, wystawcę, czas wygaśnięcia i wszystkie claims.
Przeanalizuj dane
Przejrzyj każde pole payloadu: iss (issuer), sub (subject), exp (expiration), iat (issued at), aud (audience) i wszelkie niestandardowe claims.
FAQ
Masz pytania?
JWT (JSON Web Token) to otwarty standard (RFC 7519) definiujący kompaktowy, samowystarczalny sposób przesyłania informacji między stronami jako obiekt JSON. Token jest podpisany cyfrowo, co umożliwia weryfikację jego autentyczności. Jest szeroko stosowany do uwierzytelniania i autoryzacji w REST API i nowoczesnych aplikacjach webowych.
Gdy użytkownik się loguje, serwer tworzy JWT podpisany kluczem tajnym (HS256) lub kluczem prywatnym (RS256) i wysyła go do klienta. Klient przechowuje token (zazwyczaj w pamięci lub localStorage) i dołącza go do każdego żądania jako 'Authorization: Bearer <token>'. Serwer weryfikuje podpis tokena bez odpytywania bazy danych, co czyni JWT bezstanowym mechanizmem uwierzytelniania dobrze skalującym się w systemach rozproszonych.
JWT jest podpisany, a nie zaszyfrowany. Oznacza to, że każdy może zdekodować payload i odczytać jego zawartość — dlatego nigdy nie umieszczaj w nim haseł, danych kart kredytowych ani poufnych danych. Podpis gwarantuje integralność (nikt nie może zmodyfikować tokena bez jego unieważnienia), ale nie poufność. Jeśli potrzebujesz szyfrowania zawartości, użyj JWE (JSON Web Encryption).
Claims to stwierdzenia dotyczące podmiotu tokena. Zarejestrowane claims (RFC 7519) obejmują: iss (issuer), sub (subject), exp (expiration, timestamp Unix), iat (issued at), aud (audience), nbf (not before) i jti (JWT ID). Oprócz nich możesz dodać dowolne niestandardowe claims potrzebne Twojej aplikacji.
Nie bez unieważnienia go. Jeśli zmodyfikujesz dowolną część nagłówka lub payloadu i nie posiadasz klucza tajnego do ponownego podpisania, wynikowy podpis będzie błędny i serwer odrzuci token. Istnieją jednak znane podatności: atak 'alg:none' (gdzie nagłówek deklaruje brak algorytmu, aby obejść weryfikację) oraz dezorientacja algorytmu RS256/HS256. Zawsze używaj dobrze utrzymywanej biblioteki JWT, która jawnie obsługuje te przypadki.
Sesyjne ciasteczka przechowują ID na serwerze (stanowe), podczas gdy JWT zawiera wszystkie informacje w samym tokenie (bezstanowe). JWT lepiej skaluje się w rozproszonych architekturach i mikroserwisach, ponieważ nie wymaga współdzielonych sesji. Ma jednak wady: nie możesz unieważnić tokena przed jego wygaśnięciem bez dodatkowej infrastruktury (czarna lista), a jeśli token zostanie skradziony, pozostaje ważny do wygaśnięcia. Dla większości tradycyjnych aplikacji webowych httpOnly sesyjne ciasteczka pozostają bezpieczniejszym wyborem domyślnym.
JWT: historia, struktura techniczna i bezpieczeństwo w głębi
JSON Web Token został ustandaryzowany przez IETF w maju 2015 roku jako RFC 7519, będący częścią frameworka JOSE (JSON Object Signing and Encryption). JOSE obejmuje również JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517) i JWA (JSON Web Algorithms, RFC 7518). Prace nad standardem rozpoczęły się w 2011 roku pod przewodnictwem Mike'a Jonesa (Microsoft), Johna Bradleya i Nata Sakimurego. Przed JWT programiści polegali na SAML (Security Assertion Markup Language), znacznie bardziej szczegółowym i złożonym standardzie opartym na XML.
JWT składa się z trzech części zakodowanych w Base64URL, oddzielonych kropkami. Base64URL różni się od standardowego Base64 zamieniając '+' na '-' i '/' na '_' oraz pomijając dopełnienie '=', co czyni go bezpiecznym do użycia w adresach URL i nagłówkach HTTP bez dodatkowego kodowania. Nagłówek określa typ tokena ('typ': 'JWT') i algorytm podpisywania ('alg'). Najpopularniejsze algorytmy to HS256 (HMAC-SHA256, klucz symetryczny), RS256 (RSA-SHA256, klucz asymetryczny), ES256 (ECDSA-SHA256, krzywa P-256) i niebezpieczne 'none' (brak podpisu, co nigdy nie może być akceptowane w środowisku produkcyjnym).
Najbardziej krytyczne podatności JWT są dobrze udokumentowane w OWASP API Security Top 10. Podatność 'alg:none' (CVE-2015-9235 w kilku bibliotekach) pozwala atakującemu zmodyfikować nagłówek, deklarując brak podpisu, więc serwer akceptuje dowolny payload, jeśli biblioteka nie weryfikuje jawnie algorytmu. Dezorientacja algorytmu RS256/HS256 występuje, gdy serwer skonfigurowany dla RS256 akceptuje również HS256: atakujący może użyć publicznego klucza RSA (który z definicji jest publiczny) jako tajnego klucza HMAC do podpisywania fałszywych tokenów. Nowoczesne biblioteki takie jak jose, python-jose i jsonwebtoken rozwiązują te problemy wymagając jawnego podania algorytmu podczas weryfikacji.