JSON Web Tokens: budowa, co należy do ładunku i różnica między dekodowaniem a weryfikacją

Chcesz sprawdzić, co znajduje się w tokenie? W podpisanym JWT odczytanie zawartości bywa szybkie. Ważniejsze pytanie pojawia się później: którym z tych danych aplikacja może rzeczywiście zaufać?

Artykuł dotyczy popularnej podpisanej postaci JWS z trzema częściami. Nagłówek i ładunek są zakodowane w Base64url, a nie zaszyfrowane. Szyfrowane JWT (JWE) to inna postać. Oddzielimy więc odczytywanie tokenu od jego weryfikacji.

Trzy części i co robi każda z nich

Token składa się z trzech sekcji rozdzielonych kropkami. Pierwsza podaje algorytm i często użyty klucz. Druga zawiera oświadczenia: informacje o tym, kogo dotyczy token, na co pozwala i jak długo jest ważny. Trzecia to podpis obejmujący dwie pierwsze części.

Chroni wyłącznie trzecia i chroni dokładnie jedną własność: że dwie pierwsze nie zmieniły się od chwili podpisania. Nie ukrywa ich i nie trzeba jej rozumieć, aby je odczytać. Token wklejony w dowolny dekoder natychmiast oddaje swoją zawartość.

Czego ładunek nie powinien zawierać

Każde pole w ładunku to pole wręczone posiadaczowi tokenu. Adres e-mail, pełne imię i nazwisko, data urodzenia – zamieniają dokument dostępu w przekazanie danych i trafiają tam, gdzie docierają dokumenty dostępu, a dane osobowe trafiać nie powinny: do dzienników proxy, pamięci przeglądarki, raportów o błędach.

Drugi rodzaj to struktura wewnętrzna. Lista ról w rodzaju billing_admin albo numer najemcy zdradza, co istnieje za interfejsem i jak jest uporządkowane – właśnie to atakujący wylicza w pierwszej kolejności. Zwykle wystarczy krótki podmiot i zakres; reszta należy do zapytania, które serwer i tak wykonuje.

Trzeci to wszystko, co przeznaczone było wyłącznie dla wystawcy. Tokeny wkleja się do zgłoszeń, a ładunek z wewnętrznym numerem klienta wędruje razem z nimi.

Termin ważności i reguły po stronie serwera

exp określa termin ważności. Brak tego pola nie oznacza automatycznie nieograniczonej ważności: aplikacja może go wymagać i sprawdzać dodatkowe reguły.

Usunięcie tokenu w przeglądarce nie unieważnia istniejących kopii. Wcześniejsze odrzucenie wymaga strategii po stronie serwera, np. listy blokad. Liczy się weryfikacja przez odbierającą usługę. RFC 7519: exp.

Krótko ważne tokeny dostępu i centralnie odwoływalne tokeny odświeżające to jeden z możliwych modeli. Okresy ważności zależą od aplikacji i sposobu odwoływania dostępu.

Gdzie odczyt myli się ze sprawdzeniem

Odczytanie tokenu i zaufanie mu to różne czynności, a różnicą jest wywołanie biblioteki. Dekoder pokazuje oświadczenia każdego tokenu, także takiego, który powstał ręcznie trzy sekundy temu. Weryfikacja przelicza podpis względem klucza i dopiero ona odpowiada, czy oświadczenia pochodzą od kogoś uprawnionego do ich wystawienia.

Z pomylenia obu wynikają dwa obrazy błędu. Pierwszy to alg: none – token oświadczający, że nie ma podpisu. Weryfikator, który odczytuje algorytm z tokenu i się do niego stosuje, przyjmie wszystko; algorytm musi ustalać aplikacja, a nie token. Drugi to ten sam błąd z kluczem: usługę oczekującą RS256, która dostaje token HS256, da się nakłonić do sprawdzenia go kluczem publicznym jako wspólnym sekretem – a klucz publiczny jest publiczny.

Co należy do każdego tokenu

Na trzech oświadczeniach warto nalegać. exp, bo bez niego nic się nie kończy. iss, aby usługa rozpoznała, od którego wystawcy token pochodzi, zamiast przyjmować wszystko, co da się zweryfikować. Oraz aud – to oświadczenie zapobiega przyjęciu przez interfejs rozliczeń tokenu wystawionego dla interfejsu raportów; kontrola, którą łatwo pominąć i trudno zauważyć, gdy jej brak.

Nic z tego nie wymaga rozbudowanych narzędzi. Podzielenie tokenu po kropkach i zdekodowanie środkowej części trwa sekundy i odpowiada na pytania, na które inaczej odpowiada się założeniem: jak długo to obowiązuje, na co pozwala i co zdradza każdemu, kto to przeczyta.