English
Deutsch
PolskiJSON Web Tokens: budowa, co należy do ładunku i różnica między dekodowaniem a weryfikacją
Spis treści
Token JSON Web Token wygląda na zaszyfrowany. To długi ciąg znaków bez czytelnych słów, stoi w nagłówku Authorization i traktuje się go jak tajemnicę. Czym jest naprawdę: dwoma obiektami JSON w Base64 plus podpisem – a Base64 to kodowanie, nie zamek.
Wniosek jest krótki. Wszystko w ładunku odczyta każdy, kto ma token: przeglądarka, do której trafił, proxy, przez które przeszedł, plik dziennika, który zapisał adres, i zgłoszenie, do którego ktoś go wkleił. To nie usterka, lecz budowa formatu. Problemem staje się dopiero wtedy, gdy ładunek pisze się tak, jakby nikt go nie czytał.
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 niesie oświadczenia – o kim token mówi, na co pozwala, jak długo obowiązuje. Trzecia to podpis nad dwiema pierwszymi.
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.
exp jest jedyną rzeczą kończącą token
Token obowiązuje, bo sam tak o sobie twierdzi. Nie ma stanu po stronie serwera, który by go kończył: raz wystawiony działa, aż minie oświadczenie exp, a token bez exp działa na zawsze.
Dlatego wylogowanie niczego nie unieważnia. Klient odrzuca token, token pozostaje ważny, a kto zachował kopię, zachowuje dostęp. Zakończenie tokenu przed czasem wymaga listy odrzuceń sprawdzanej przez każdą usługę – czyli powrotu dokładnie tego wspólnego stanu, którego format miał unikać.
Układem, który działa, jest krótko żyjący token dostępu i odwoływalny centralnie token odświeżający. Minuty dla pierwszego, a dla drugiego czas życia, który ktoś faktycznie obserwuje: token odświeżający ważny rok to hasło z dodatkowymi krokami.
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.
Pytania i odpowiedzi
Co dzieje się z wystawionymi już tokenami, gdy zmienia się klucz podpisu?
Pozostają ważne tak długo, jak długo weryfikator zna jeszcze stary klucz. Podpis przelicza się względem klucza z własnej listy weryfikatora, zwykle tego, który wskazuje pierwsza część tokenu. Gdy ten klucz zniknie z listy, każdy podpisany nim token od razu przestaje przechodzić weryfikację, niezależnie od tego, co stoi w exp.
Przy planowanej zmianie wynika z tego kolejność. Najpierw weryfikatory poznają nowy klucz, potem wystawca zaczyna nim podpisywać, a stary klucz zostaje, dopóki nie wygaśnie ostatni podpisany nim token. Przy tokenach dostępu żyjących kilka minut okres nakładania się jest krótki; jeśli także tokeny odświeżające są wystawiane jako podpisane tokeny, sięga on tak daleko jak ich czas życia.
Z drugiej strony usunięcie klucza kończy przed czasem wszystkie podpisane nim tokeny, całkiem bez listy odrzuceń. To właściwy krok, gdy klucz podpisu wpadł w niepowołane ręce, ale dotyka naraz wszystkich klientów. W każdym przypadku wskazanie klucza w tokenie powinno służyć wyłącznie do wyboru spośród kluczy, które weryfikator sam przechowuje, z tego samego powodu, dla którego algorytm nie może pochodzić z tokenu.
Czy zamiast skracać ładunek, da się go zaszyfrować?
Tak, za pomocą JSON Web Encryption według RFC 7516; wtedy zawartość odczyta tylko ten, kto ma klucz. Token pozostaje jednak dokumentem dostępu: kopia w zgłoszeniu albo w pliku dziennika staje się nieczytelna, ale do upływu exp działa tak samo jak wcześniej. Pole, które serwer i tak może sprawdzić sam, nie potrzebuje więc szyfrowania, tylko w ogóle nie powinno trafiać do tokenu.
Co oznacza dla exp rozbieżność zegarów między serwerami?
exp to punkt w czasie, porównywany z zegarem usługi weryfikującej, a nie wystawcy. Jeśli ten zegar się spóźnia, usługa przyjmuje jeszcze token, który już wygasł. Jeśli się spieszy, czas życia skraca się o różnicę, a przy tokenie dostępu żyjącym kilka minut już jedna minuta to odczuwalna część. Przy nbf, czyli chwili, od której token obowiązuje, różnica działa odwrotnie: usługa ze spóźniającym się zegarem odrzuca świeżo wystawiony token jako jeszcze nieważny.
RFC 7519 dopuszcza w tym celu niewielką tolerancję, zwykle nie większą niż kilka minut, a większość bibliotek oferuje odpowiednie ustawienie. Tolerancja wydłuża jednak każdy token dokładnie o tę wartość, a dwie minuty tolerancji przy tokenie dostępu ważnym pięć minut to nie drobiazg. Pewniejsze jest synchronizowanie wszystkich zaangażowanych maszyn przez NTP i pozostawienie tolerancji na poziomie kilku sekund.
Powiązane artykuły
