Skip to main content
CheckTown
Walidatory

Walidator JWT: Sprawdz strukture i roszczenia JSON Web Token

Opublikowano 6 min czytania
W tym artykule

Czym jest JWT?

JWT (JSON Web Token) to kompaktowy, bezpieczny dla URL format tokenu używany do bezpiecznego przesyłania informacji między stronami jako obiekt JSON. Zdefiniowany przez RFC 7519, JWT-y są de facto standardem uwierzytelniania i autoryzacji w nowoczesnych aplikacjach webowych i API.

JWT-y są samowystarczalne — przenoszą wszystkie informacje potrzebne do weryfikacji autentyczności tokenu i wyodrębniania roszczeń użytkownika bez zapytania do bazy danych. Czyni je to idealnymi do bezstanowego uwierzytelniania w rozproszonych systemach i architekturach mikroserwisów.

Struktura JWT

JWT składa się z trzech części zakodowanych w Base64URL oddzielonych kropkami: nagłówek.ładunek.podpis.

  • Nagłówek — obiekt JSON określający typ tokenu (JWT) i algorytm podpisywania (np. HS256, RS256, ES256)
  • Ładunek — obiekt JSON zawierający roszczenia: zarejestrowane roszczenia (iss, sub, exp, iat), roszczenia publiczne i prywatne
  • Podpis — tworzony przez podpisanie zakodowanego nagłówka i ładunku kluczem tajnym (HMAC) lub kluczem prywatnym (RSA/ECDSA)

Wypróbuj za darmo — bez rejestracji

Zwaliduj JWT →

Jak działa walidacja JWT

Walidacja JWT obejmuje sprawdzanie struktury, weryfikację podpisu i walidację roszczeń.

  • Sprawdzanie struktury — token musi zawierać dokładnie trzy segmenty zakodowane w Base64URL oddzielone dwoma kropkami
  • Walidacja nagłówka — nagłówek musi zawierać prawidłowe pola typ i alg. Algorytm musi odpowiadać temu, czego oczekuje serwer
  • Weryfikacja podpisu — podpis jest przeliczany przy użyciu nagłówka, ładunku i klucza podpisywania. Jeśli przeliczony podpis pasuje, token nie został zmodyfikowany
  • Walidacja roszczeń — roszczenia exp (wygaśnięcie), nbf (nie przed) i iss (wystawca) są sprawdzane względem bieżącego czasu i oczekiwanych wartości

Typowe przypadki użycia

JWT-y zapewniają uwierzytelnianie i autoryzację w całym nowoczesnym stosie technologicznym.

  • Uwierzytelnianie API — klienci dołączają JWT-y w nagłówkach Authorization (schemat Bearer) do uwierzytelniania żądań API bez sesji
  • Jednokrotne logowanie (SSO) — dostawcy tożsamości wydają JWT-y akceptowane przez wiele aplikacji, umożliwiając płynne uwierzytelnianie między aplikacjami
  • Tokeny dostępu OAuth 2.0 — wiele implementacji OAuth używa JWT-ów jako tokenów dostępu, kodując zakresy i uprawnienia bezpośrednio w tokenie
  • Komunikacja mikroserwisów — usługi przekazują JWT-y do propagowania kontekstu użytkownika i decyzji autoryzacyjnych między granicami usług

Najlepsze praktyki bezpieczeństwa JWT

JWT-y są potężne, ale wymagają ostrożnej obsługi, aby uniknąć typowych pułapek bezpieczeństwa.

  • Zawsze weryfikuj algorytm — nigdy nie pozwól, aby pole alg z tokenu dyktowało, jakiego algorytmu używa twój serwer. Zapobiega to atakowi algorytmu none
  • Ustaw krótkie czasy wygasania — JWT-ów nie można unieważnić po ich wystawieniu. Utrzymuj krótkie czasy exp (15 minut dla tokenów dostępu) i używaj tokenów odświeżania dla długotrwałych sesji
  • Używaj algorytmów asymetrycznych dla systemów rozproszonych — RS256 lub ES256 pozwalają usługom weryfikować tokeny bez udostępniania sekretu podpisywania
  • Nigdy nie przechowuj wrażliwych danych w ładunku — JWT-y są kodowane, nie szyfrowane. Każdy może zdekodować ładunek. Przechowuj sekrety w swojej bazie danych, nie w tokenie

Często zadawane pytania

Czy JWT może być zdekodowany bez klucza tajnego?

Tak. Ładunki JWT są zakodowane w Base64URL, nie szyfrowane. Każdy może zdekodować i odczytać nagłówek i ładunek. Klucz tajny jest potrzebny tylko do weryfikacji podpisu — aby potwierdzić, że token nie został zmieniony.

Jaka jest różnica między JWS a JWE?

JWS (JSON Web Signature) to to, co większość ludzi rozumie przez JWT — podpisany token. JWE (JSON Web Encryption) to szyfrowany token, w którym ładunek nie może być odczytany bez klucza deszyfrowania. Większość JWT-ów to tokeny JWS.

Czy powinienem przechowywać JWT-y w localStorage czy w cookies?

Cookies HttpOnly są bezpieczniejsze, ponieważ nie są dostępne przez JavaScript (zapobiegając kradzieży XSS). localStorage jest podatne na ataki XSS. W przypadku wrażliwych aplikacji używaj cookies HttpOnly Secure SameSite.

Powiązane narzędzia