Weryfikator podpisu JWT

Weryfikator podpisu JWT – weryfikacja HMAC i RSA w przeglądarce

Weryfikacja podpisu JWT to kluczowy krok bezpieczeństwa. Narzędzie weryfikuje podpis tokenu JWT dla algorytmów HS256 (HMAC-SHA256) i RS256 (RSA-SHA256) bezpośrednio w przeglądarce – bez wysyłania tokenu na zewnętrzny serwer, co jest bezpieczne dla produkcyjnych tokenów.

Mechanika weryfikacji: co dokładnie liczy przeglądarka

Podpis JWT nie szyfruje treści – to skrót kryptograficzny, który dowodzi, że nagłówek i ładunek nie zostały zmienione po wystawieniu tokenu. Przeglądarka składa tak zwany signing input: dokładnie te same dwa pierwsze segmenty tokenu, sklejone kropką, potraktowane jako znaki ASCII. Następnie liczy skrót SHA-256 z tego napisu i wiąże go z kluczem – w HS256 przez HMAC, w RS256 przez operację na kluczu RSA z dopełnieniem PKCS#1 v1.5. Dopiero tak powstała wartość jest porównywana z trzecim segmentem tokenu.

W HS256 klucz jest jeden: ten sam sekret podpisuje i weryfikuje. HMAC-SHA256 zwraca zawsze 32 bajty, które w base64url – bez znaków wyrównania – dają 43 znaki. W RS256 długość podpisu wynika z długości modułu klucza: klucz 2048-bitowy daje 256 bajtów, czyli 342 znaki base64url, a 4096-bitowy 512 bajtów, czyli 683 znaki. Już po samej długości trzeciego segmentu można więc wstępnie ocenić, z jakim algorytmem i jaką długością klucza mamy do czynienia, choć sama długość nie jest dowodem poprawności.

Porównanie podpisów musi być odporne na pomiar czasu, dlatego bajty zestawia się w stałym czasie – z liczby wykonanych operacji nie da się wywnioskować, po ilu znakach porównanie się rozjechało. Dla RS256 narzędzie korzysta z Web Crypto API: SubtleCrypto.verify() sprawdza matematycznie, czy podpis mógł powstać z klucza prywatnego odpowiadającego wklejonemu kluczowi publicznemu. Wynik valid oznacza wyłącznie zgodność podpisu z kluczem – nie mówi nic o tym, czy token nie wygasł ani czy wystawił go właściwy serwis.

Przykład: weryfikacja tokenu HS256 krok po kroku

1. Bierzemy token HS256 zbudowany z trzech segmentów rozdzielonych kropkami. Pierwszy segment to eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9, drugi to zakodowany ładunek, trzeci to podpis.
2. Dekodujemy base64url pierwszego segmentu i otrzymujemy {"alg":"HS256","typ":"JWT"}. Sprawdzamy, że algorytm to HS256 – a nie none ani RS256. To pierwszy punkt kontrolny, bo pole alg pochodzi z tokenu, a nie z konfiguracji aplikacji.
3. Sklejamy signing input: pierwszy segment + kropka + drugi segment, znak w znak. Nie dopisujemy znaków wyrównania, nie zmieniamy wielkości liter, nie dodajemy spacji ani końcowego znaku nowej linii.
4. Pobieramy sekret, którym token podpisano, i traktujemy go jako ciąg bajtów w UTF-8. Liczymy HMAC-SHA256 z sekretu i signing input – wynikiem jest 32 bajty.
5. Kodujemy te 32 bajty w base64url. Powstaje 43 znaki – dokładnie taki ciąg powinien znajdować się w trzecim segmencie tokenu.
6. Porównujemy oczekiwane 43 znaki z tym, co jest w tokenie. Identyczny ciąg daje wynik valid, różnica choćby jednego znaku to invalid. Na koniec narzędzie odczytuje pole exp i pokazuje, czy token nie wygasł.

Rozmiary podpisów i klucze dla typowych algorytmów

Jak używać weryfikatora bez wpadek

• Wymuszaj algorytm po stronie serwera – pole alg z nagłówka tokenu to dane wejściowe od potencjalnego atakującego. Weryfikator pokazuje, jaki algorytm faktycznie zadeklarowano, ale to Twoja aplikacja musi odrzucać wszystko poza oczekiwanym HS256 lub RS256.
• Zadbaj o entropię sekretu w HS256 – HMAC nie naprawi słabego klucza. Krótki, słownikowy sekret można złamać metodą siłową offline, bo atakujący ma cały token i może zgadywać w nieskończoność.
• Do RS256 wklejaj wyłącznie klucz publiczny – fragment zaczynający się od nagłówka klucza publicznego. Klucza prywatnego nie ma po co wklejać do przeglądarki, a JWKS pobieraj tylko z zaufanego adresu po HTTPS.
• Sprawdź claims osobno – poprawny podpis nie znaczy, że token jest aktualny. Po wyniku valid przejrzyj exp, nbf, iss i aud, bo to one decydują o przyjęciu tokenu.
• Zrób test negatywny – zmień jeden znak w drugim segmencie i sprawdź, czy narzędzie zwraca invalid. To najszybszy sposób potwierdzenia, że porównujesz właściwy podpis z właściwym kluczem.

Czego weryfikator nie sprawdzi

• Algorytmów spoza HS256 i RS256 – token podpisany jako ES256, PS256 czy HS512 zostanie rozpoznany po nagłówku, ale weryfikacji podpisu nie wykonasz. Tabela rozmiarów podpisów ma charakter referencyjny, nie jest listą obsługiwanych metod.
• Twojej polityki ważności tokenu – narzędzie odczyta exp, ale nie wie, jakiego wystawcy (iss) i odbiorcy (aud) oczekujesz ani czy dany identyfikator tokenu (jti) nie trafił na blacklistę.
• Rotacji kluczy i łańcucha certyfikatów – przy JWKS zawierającym wiele kluczy trzeba samodzielnie wskazać ten zgodny z polem kid z nagłówka; weryfikator nie przeszuka wszystkich ani nie sprawdzi daty ważności certyfikatu.
• Bezpieczeństwa środowiska lokalnego – obliczenia odbywają się w przeglądarce, więc wklejony klucz pozostaje w pamięci karty do jej zamknięcia. Na komputerze współdzielonym lub z niezaufanym rozszerzeniem wynik może być obserwowany.

Najczęstsze pytania

Powiązane narzedzia: analizator JWT, koder base64 i generator klucza API.