Dekoder JWT
Dekoduj i sprawdzaj tokeny JSON Web Token
Token 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.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"alg": "HS256",
"typ": "JWT"
}{
"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.
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.
| Claim | Opis | Typ |
|---|---|---|
| iss | Wystawca — Identyfikuje, kto wystawił token — np. URL serwera autoryzacji lub nazwa aplikacji. | string |
| sub | Podmiot — Identyfikuje podmiot, którego dotyczy JWT — zazwyczaj ID użytkownika lub konto serwisowe. | string |
| aud | Odbiorca — Identyfikuje zamierzonych odbiorców. Strona odbierająca musi zweryfikować, że odpowiada to jej identyfikatorowi. | string | string[] |
| exp | Czas wygaśnięcia — Znacznik czasu Unix, po którym token nie może być akceptowany. Zawsze ustaw to, aby ograniczyć szkody wynikające z kradzieży tokenu. | number |
| nbf | Nie przed — Znacznik czasu Unix, przed którym token nie może być akceptowany. Przydatne do planowania tokenów z przyszłą datą. | number |
| iat | Wystawiony o — Znacznik czasu Unix, w którym token został wystawiony. Używany do obliczenia wieku tokenu. | number |
| jti | JWT ID — Unikalny 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.
| Algorytm | Rodzina | Typ klucza | Uwagi |
|---|---|---|---|
| HS256 | HMAC | Symmetric | Najpopularniejszy. Wspólny sekret — każdy, kto ma sekret, może podpisywać i weryfikować. |
| HS384 | HMAC | Symmetric | Silniejszy wariant HMAC; umiarkowany koszt wydajności. |
| HS512 | HMAC | Symmetric | Najsilniejszy wariant HMAC. |
| RS256 | RSA | Asymmetric | Najszerzej stosowany algorytm asymetryczny (Google, Auth0, Okta). Klucz publiczny weryfikuje bez klucza prywatnego. |
| RS384 | RSA | Asymmetric | Wariant RS o wyższym bezpieczeństwie. |
| RS512 | RSA | Asymmetric | Najsilniejszy wariant RS. |
| ES256 | ECDSA | Asymmetric | Krzywa eliptyczna — krótsze podpisy niż RSA, popularne na urządzeniach mobilnych i IoT. |
| PS256 | RSA-PSS | Asymmetric | RSA-PSS: nowocześniejszy i bezpieczniejszy niż oparty na PKCS1v1.5 RS256. |
| none | — | — | Brak 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.
- –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
- –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
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.
function decodeJWT(token) {
const [, payload] = token.split('.')
const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
return JSON.parse(json)
}const [, payload] = token.split('.')
const decoded = JSON.parse(
Buffer.from(payload, 'base64url').toString()
)import base64, json
def decode_jwt(token):
payload = token.split('.')[1]
padding = '=' * (-len(payload) % 4)
return json.loads(base64.urlsafe_b64decode(payload + padding))TOKEN="eyJhbGc..." echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .