Dekoder JWT

Dekoduj i sprawdzaj tokeny JSON Web Token

Wypróbuj przykład

Token JWT

Działa lokalnie · Bezpieczne do wklejania sekretów
Wypróbuj też:Koder JWT

Czym jest JWT (JSON Web Token)?

JSON Web Token (JWT) to kompaktowy, bezpieczny dla URL format tokenu zdefiniowany w RFC 7519. Koduje zestaw claims jako obiekt JSON, a następnie podpisuje go — i opcjonalnie szyfruje — tak, aby odbiorca mógł zweryfikować, że dane nie zostały zmienione. JWT są de facto standardem bezstanowego uwierzytelniania w REST API, systemach logowania jednokrotnego i autoryzacji mikroserwisów.

Anatomia JWT: Header · Payload · Signature

Każdy JWT składa się z trzech segmentów zakodowanych w base64url, oddzielonych kropkami. Header i Payload to zwykły JSON — czytelny dla każdego — natomiast Signature to wartość kryptograficzna, którą można zweryfikować tylko przy użyciu właściwego klucza.

Zakodowany token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Po co używać dekodera JWT?

Surowe JWT wyglądają jak losowy tekst. To narzędzie natychmiast renderuje Header i Payload jako sformatowany JSON, dzięki czemu możesz sprawdzać claims, weryfikować czasy wygaśnięcia i audytować wybory algorytmów bez pisania ani jednej linii kodu.

🔍
Natychmiastowa inspekcja claims
Przeglądaj każdy claim w Payload — sub, iss, aud, exp, niestandardowe role, uprawnienia — sformatowany i czytelny jednym kliknięciem.
🔓
Klucz tajny nie jest wymagany
Header i Payload są publiczne; tylko Signature wymaga sekretu. To narzędzie dekoduje oba bez Twojego klucza podpisu.
⏱️
Analiza wygasania i znaczników czasu
Znaczniki czasu Unix (exp, iat, nbf) są automatycznie konwertowane na czytelne daty, dzięki czemu od razu widać, czy token wygasł.
🔒
Działa całkowicie w przeglądarce
Wszystko jest przetwarzane lokalnie — żadne dane tokenu nie są wysyłane na żaden serwer. Bezpieczne do użycia z tokenami produkcyjnymi podczas debugowania.

Referencyjna lista standardowych claims JWT

RFC 7519 definiuje siedem zarejestrowanych nazw claims. Nie są one wymagane, ale ich użycie jest zdecydowanie zalecane dla interoperacyjności. Do Payload możesz dodać dowolne niestandardowe claims.

ClaimOpisTyp
issWystawcaIdentyfikuje, kto wystawił token — np. URL serwera autoryzacji lub nazwa aplikacji.string
subPodmiotIdentyfikuje podmiot, którego dotyczy JWT — zazwyczaj ID użytkownika lub konto serwisowe.string
audOdbiorcaIdentyfikuje zamierzonych odbiorców. Strona odbierająca musi zweryfikować, że odpowiada to jej identyfikatorowi.string | string[]
expCzas wygaśnięciaZnacznik czasu Unix, po którym token nie może być akceptowany. Zawsze ustaw to, aby ograniczyć szkody wynikające z kradzieży tokenu.number
nbfNie przedZnacznik czasu Unix, przed którym token nie może być akceptowany. Przydatne do planowania tokenów z przyszłą datą.number
iatWystawiony oZnacznik czasu Unix, w którym token został wystawiony. Używany do obliczenia wieku tokenu.number
jtiJWT IDUnikalny identyfikator tokenu. Umożliwia unieważnienie poprzez przechowywanie i sprawdzanie użytych wartości JTI po stronie serwera.string

Algorytmy podpisu JWT

Claim nagłówka alg deklaruje, którym algorytmem podpisano token. Wybór wpływa na bezpieczeństwo, wydajność i to, czy usługi zewnętrzne mogą weryfikować tokeny bez klucza prywatnego.

AlgorytmRodzinaTyp kluczaUwagi
HS256HMACSymmetricNajpopularniejszy. Wspólny sekret — każdy, kto ma sekret, może podpisywać i weryfikować.
HS384HMACSymmetricSilniejszy wariant HMAC; umiarkowany koszt wydajności.
HS512HMACSymmetricNajsilniejszy wariant HMAC.
RS256RSAAsymmetricNajszerzej stosowany algorytm asymetryczny (Google, Auth0, Okta). Klucz publiczny weryfikuje bez klucza prywatnego.
RS384RSAAsymmetricWariant RS o wyższym bezpieczeństwie.
RS512RSAAsymmetricNajsilniejszy wariant RS.
ES256ECDSAAsymmetricKrzywa eliptyczna — krótsze podpisy niż RSA, popularne na urządzeniach mobilnych i IoT.
PS256RSA-PSSAsymmetricRSA-PSS: nowocześniejszy i bezpieczniejszy niż oparty na PKCS1v1.5 RS256.
noneBrak podpisu — krytycznie niebezpieczny. Nigdy nie akceptuj tokenów z alg: none w środowisku produkcyjnym.

Zagadnienia bezpieczeństwa

Dekodowanie JWT jest zawsze bezpieczne. Ufanie JWT bez właściwej weryfikacji podpisu już nie. Pamiętaj o tych zasadach za każdym razem, gdy używasz tokenów w swojej aplikacji.

Zawsze bezpieczne
  • Dekodowanie i sprawdzanie JWT w narzędziach deweloperskich lub tym narzędziu
  • Używanie exp, iat i nbf do zrozumienia czasu życia tokenu
  • Logowanie claims Payload do debugowania (pominąć wrażliwe dane osobowe)
  • Czytanie nagłówka alg w celu zrozumienia sposobu podpisania tokenu
Nigdy nie rób tego
  • Ufanie claims w Payload bez weryfikacji podpisu po stronie serwera
  • Akceptowanie tokenów z alg: none — oznacza to brak jakiegokolwiek podpisu
  • Przechowywanie tokenów dostępu w localStorage w aplikacjach o wysokich wymaganiach bezpieczeństwa (preferuj ciasteczka httpOnly)
  • Ustawianie exp daleko w przyszłości dla tokenów niosących wrażliwe uprawnienia

Typowe przypadki użycia

Debugowanie przepływów uwierzytelniania
Wklej token z karty sieciowej przeglądarki, aby sprawdzić claims, zweryfikować wbudowane role i sprawdzić wygasanie bez dotykania kodu produkcyjnego.
Inspekcja tokenów zewnętrznych
Szybko odczytuj tokeny od Google, Auth0, Okta lub Azure AD, aby zobaczyć, jakie claims zawiera Twój dostawca i porównać je z oczekiwanym schematem.
Programowanie i testowanie API
Podczas pisania lub testowania endpointów API dekoduj nagłówek autoryzacji, aby potwierdzić, że logika generowania tokenów ustawia właściwe wartości sub, aud i scope.
Autoryzacja mikroserwisów
W siatce usług każdy serwis weryfikuje JWT od wywołującego z wyższego poziomu. Dekoduj tokeny, aby śledzić, który serwis wystawił token i jakie uprawnienia deklaruje.
Wsparcie i reagowanie na incydenty
Gdy użytkownik zgłasza błąd uwierzytelniania, zdekoduj jego token, aby sprawdzić, czy wygasł, czy odbiorca jest nieprawidłowy lub czy brakuje wymaganego claim.
Audyt bezpieczeństwa
Audytuj użycie JWT w serwisach, sprawdzając wybory algorytmów, okna wygasania i czy wrażliwe dane są przypadkowo przechowywane w niezaszyfrowanym Payload.

Dekodowanie JWT w kodzie

Header i Payload są zakodowane w base64url — wystarczy odwrócić kodowanie. Base64url zastępuje + przez - i / przez _, pomijając wypełnienie =. Tylko Signature wymaga klucza tajnego.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

Często zadawane pytania

Czy mogę zdekodować JWT bez klucza tajnego?
Tak. Header i Payload JWT to po prostu JSON zakodowany w base64url — nie szyfrowany. Każdy może je zdekodować i odczytać. Sekret (lub klucz prywatny dla algorytmów RS/ES) jest potrzebny tylko do weryfikacji podpisu, potwierdzając, że token nie został zmieniony.
Czy dekodowanie JWT oznacza, że podpis jest zweryfikowany?
Nie. Dekodowanie tylko odczytuje claims. Weryfikacja to odrębny krok, który sprawdza podpis kryptograficzny przy użyciu właściwego klucza. Zawsze weryfikuj podpis przed zaufaniem jakimkolwiek claims w swojej aplikacji.
Jaka jest różnica między HS256 a RS256?
HS256 używa jednego symetrycznego sekretu współdzielonego między wystawcą a weryfikatorem — każdy, kto ma sekret, może tworzyć i weryfikować tokeny. RS256 używa asymetrycznej pary kluczy: klucz prywatny podpisuje, klucz publiczny weryfikuje. Dzięki RS256 możesz dystrybuować klucz publiczny, aby zewnętrzne serwisy mogły weryfikować tokeny bez możliwości ich fałszowania.
Dlaczego dekodowanie base64 czasami się nie udaje?
JWT używają kodowania base64url, które używa - zamiast + i _ zamiast /, pomijając znaki wypełnienia =. Standardowe dekodery base64 wymagają + i / i mogą wymagać wypełnienia. Przed ręcznym dekodowaniem dodaj wypełnienie (do wielokrotności 4 za pomocą =) i zamień znaki.
Czy bezpieczne jest wklejenie produkcyjnego JWT do tego narzędzia?
Tak — narzędzie działa całkowicie w przeglądarce i nie wysyła żadnych danych na serwer. Jednak uważaj, kto może widzieć Twój ekran lub historię przeglądarki. W przypadku wysoce wrażliwych tokenów zdekoduj je lokalnie w terminalu.
Co oznacza alg: none i czy jest niebezpieczne?
alg: none oznacza, że token nie ma podpisu kryptograficznego — każdy może stworzyć token z dowolnymi claims i ustawić alg na none. Niektóre wczesne biblioteki JWT akceptowały te tokeny, tworząc krytyczną lukę w zabezpieczeniach. Bezpieczna biblioteka JWT zawsze odrzuca tokeny z alg: none, chyba że jawnie skonfigurowano inaczej. Nigdy nie wyłączaj tej kontroli.