Co jest w JWT i dlaczego dekodowanie to nie weryfikacja

JSON Web Token (JWT) to trzy fragmenty tekstu połączone kropkami: nagłówek, ładunek (payload) i podpis. Dwa pierwsze są jedynie zakodowane, nie zaszyfrowane, więc każdy, kto ma token, może je odczytać. Podpis pozwala serwerowi sprawdzić, czy token wystawiła zaufana strona i czy nikt go nie zmienił. Dekodowanie tokenu mówi, co on zawiera. Dopiero weryfikacja mówi, czy można mu wierzyć.

Dekoder JWTToken wygasł, czy jest ważny?Zrób to za darmo

Trzy części

Token wygląda tak: header.payload.signature. Pierwsza część znanego przykładowego tokenu z jwt.io to:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Każda z dwóch pierwszych części to JSON zamieniony na base64url, czyli postać tekstu bezpieczną w adresach URL. Pierwsza część po zdekodowaniu daje:

{"alg":"HS256","typ":"JWT"}

Ładunek tego samego przykładu po zdekodowaniu daje:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

Ładunek zawiera roszczenia (claims), czyli stwierdzenia o użytkowniku lub sesji. Podpis jest obliczany z dwóch pierwszych części i klucza, więc zmiana jednego znaku powoduje, że przestaje pasować. Base64url da się odwrócić bez klucza, dlatego nigdy nie umieszczaj w ładunku hasła, klucza prywatnego ani danych osobowych.

Zarejestrowane roszczenia

RFC 7519, standard dla JWT, zarezerwowuje kilka krótkich nazw roszczeń:

iss (issuer): kto utworzył token.
sub (subject): kogo dotyczy token, zwykle identyfikator użytkownika.
aud (audience): usługa, dla której token jest przeznaczony.
exp (expiration time): moment, po którym token jest nieważny.
nbf (not before): najwcześniejszy moment, w którym token jest ważny.
iat (issued at): kiedy token został utworzony.

Czas to liczba sekund od 1 stycznia 1970 roku UTC, zwana czasem Unix. Przykład nie ma exp, więc zgodnie ze standardem nigdy nie wygasa. Prawdziwy token powinien go mieć. Inne nazwy, na przykład role czy email, należą do aplikacji.

Dekodowanie to nie weryfikacja

Dekodowanie dzieli token na kropkach, odwraca base64url i odczytuje JSON. Pokazuje, co token deklaruje, i robi to samo dla sfałszowanego tokenu, bo każdy może wpisać dowolne roszczenia z dowolnym podpisem.

Weryfikacja ponownie oblicza podpis przy użyciu właściwego klucza i sprawdza, czy się zgadza. Sprawdza też, czy exp i nbf obejmują bieżący czas, oraz czy iss i aud mają wartości oczekiwane przez usługę. Aplikacja, która odczytuje roszczenie role bez weryfikacji, ufa każdemu, kto napisał token. To częsty błąd.

HS256, RS256 i ES256

Wartość alg nazywa metodę. Są trzy popularne:

HS256 to HMAC z SHA-256. Jeden wspólny sekret podpisuje i weryfikuje, więc musi pozostać na serwerze wystawiającym tokeny.
RS256 to podpis RSA z SHA-256. Wystawca podpisuje kluczem prywatnym, a każdy, kto ma klucz publiczny, może weryfikować. Inne usługi mogą sprawdzać tokeny, ale nie mogą ich tworzyć.
ES256 to podpis ECDSA z krzywą P-256 i SHA-256. Działa jak RS256, ale z mniejszymi kluczami i podpisami.

Używaj HS256, gdy jedna usługa zarówno wystawia, jak i sprawdza swoje tokeny. Używaj RS256 lub ES256, gdy inne usługi muszą sprawdzać tokeny, których nie wystawiły.

Problemy wynikające z ufania nagłówkowi

Nagłówek pisze ten, kto wysyła token, więc weryfikator nie może pozwolić mu wybierać reguł.

alg: none. Token bez podpisu może zadeklarować "alg":"none". Niektóre biblioteki kiedyś akceptowały takie tokeny i pomijały sprawdzenie. Ustaw dozwolone algorytmy we własnym kodzie, nigdy nie pobieraj ich z tokenu.
Pomylenie algorytmów. Serwer oczekuje RS256 i ma klucz publiczny. Atakujący wysyła token HS256 podpisany tym kluczem publicznym jako sekretem HMAC. Weryfikator, który akceptuje dowolny algorytm wskazany w nagłówku, go przyjmie. Przypisz każdy klucz dokładnie do jednego algorytmu.
Słabe sekrety. Atakujący ma nagłówek, ładunek i podpis, więc może testować kandydujące sekrety offline. Krótki sekret albo popularne słowo szybko wpadają na taką listę. RFC 7518 mówi, że klucz HS256 powinien mieć co najmniej 256 bitów i być losowy.

Wklejanie tokenu produkcyjnego na stronę

Ważny, niewygasły token działa dla każdego, kto go posiada, aż do wygaśnięcia. Traktuj go jak hasło. Zanim wkleisz go na stronę, sprawdź, czy strona wysyła go na serwer. Narzędzie działające w całości w karcie przeglądarki nie musi tego robić. Dowolną stronę możesz sprawdzić, obserwując żądania sieciowe w narzędziach deweloperskich przeglądarki.

Tokenów zwykle nie da się unieważnić przed wygaśnięciem, chyba że serwer prowadzi ich listę. Jeśli aktywny token wycieknie, poproś usługę o unieważnienie sesji lub wymianę kluczy. Do debugowania, gdzie to możliwe, używaj tokenu ze środowiska testowego. Dekoder JWT odczytuje trzy części w karcie przeglądarki, a nic z tego, co wkleisz, nie jest nigdzie wysyłane.

Webhooki: ta sama idea ze wspólnym sekretem

Większość dostawców webhooków wysyła w nagłówku HMAC treści żądania, obliczony przy użyciu sekretu, który wcześniej udostępniłeś im wspólnie. Twój odbiorca oblicza ten sam HMAC i porównuje oba. Częste błędy są drobne. JSON zostaje ponownie sformatowany przed haszowaniem, więc zmieniają się bajty. Testowy sekret jest użyty na ruchu na żywo. Albo podpisy porównuje się zwykłą równością łańcuchów, co może ujawnić informacje o czasie. Użyj porównania o stałym czasie.

Tester podpisu webhooka oblicza podpis z wklejonego sekretu i treści dla GitHuba, Stripe, Slacka, Shopify lub dowolnego schematu HMAC, dzięki czemu widzisz, czy obie wartości się zgadzają.

Szybkie odpowiedzi

Czy JWT jest zaszyfrowany?

Nie. Standardowy JWT jest podpisany, a każdy może odczytać jego nagłówek i ładunek. Chroni go przed zmianami wyłącznie podpis.

Co się stanie, jeśli zmienię ładunek?

Podpis przestanie pasować, więc weryfikujący serwer odrzuci token. Odczyt roszczeń nie sprawdza podpisu, więc dekoder nadal pokaże Twoją zmienioną wersję.