Co to jest JWT? Zrozumienie tokenów internetowych JSON i uwierzytelniania bezstanowego

Kiedy logujesz się do nowoczesnej aplikacji jednostronicowej (takiej jak React lub Vue) lub aplikacji mobilnej, serwer potrzebuje sposobu, aby zapamiętać, kim jesteś. Tradycyjnie robiło to poprzez przechowywanie „identyfikatora sesji” w ogromnej bazie danych na serwerze i umieszczanie pliku cookie w przeglądarce. Za każdym razem, gdy kliknąłeś przycisk, serwer musiał sprawdzić ten identyfikator w swojej bazie danych. Nazywa się to uwierzytelnianiem stanowym.

Jednak w dobie mikroserwisów i skalowania chmur bazy danych stały się wąskim gardłem. Aby rozwiązać ten problem, programiści przyjęli uwierzytelnianie bezstanowe za pośrednictwem tokenów internetowych JSON (JWT). Dzięki JWT serwer nie musi pamiętać, kim jesteś — Twoja przeglądarka dokładnie informuje serwer, kim jesteś, i potwierdza to za pomocą kryptografii.

Anatomia JWT

Jeśli sprawdzisz ruch sieciowy po zalogowaniu się do nowoczesnej aplikacji, prawdopodobnie zobaczysz nagłówek „Authorization: Bearer”, po którym następuje długi, losowo wyglądający ciąg znaków oddzielonych dwiema kropkami. To jest JWT.

JWT składa się dokładnie z trzech części: Header.Payload.Signature.

1. Nagłówek

Pierwsza część to obiekt JSON zakodowany w formacie Base64URL, który po prostu opisuje token. Zwykle zawiera dwie właściwości: typ tokena (JWT) i używany algorytm podpisywania (taki jak HMAC SHA256 lub RSA).

2. Ładunek (roszczenia)

Środkowa część to także obiekt JSON zakodowany w formacie Base64URL. To tutaj znajdują się rzeczywiste dane. Te dane nazywane są „twierdzeniami”. Może na przykład zawierać Twój identyfikator użytkownika, Twoją rolę (np. „Administrator”) i sygnaturę czasową wygaśnięcia. Ponieważ ten ładunek jest dołączany do każdego żądania, serwer natychmiast wie, kim jesteś, bez wysyłania zapytań do bazy danych.

KRYTYCZNE OSTRZEŻENIE: ładunek jest jedynie zakodowany, nie szyfrowany. Każdy, kto przechwyci JWT, może go z łatwością odszyfrować i odczytać ładunek. Nigdy nie przechowuj haseł, numerów ubezpieczenia społecznego ani poufnych danych w ładunku JWT.

3. Podpis

Jeśli każdy może odczytać i edytować ładunek, co powstrzymuje złośliwego użytkownika przed zmianą roli z „Użytkownik” na „Administrator”? Odpowiedzią jest podpis.

Aby utworzyć podpis, serwer pobiera nagłówek, ładunek i bardzo bezpieczny tajny klucz (znany tylko serwerowi) i przepuszcza je przez algorytm kryptograficzny (np. SHA256). Powstały skrót staje się podpisem.

Kiedy serwer otrzyma token od klienta, ponownie oblicza podpis przy użyciu swojego tajnego klucza. Jeśli użytkownik majstrował przy ładunku (nawet zmieniając jedną literę), przeliczony podpis nie będzie zgodny z podpisem na tokenie, a serwer natychmiast odrzuci żądanie jako fałszywe.

Dlaczego mikrousługi uwielbiają JWT

Wyobraź sobie firmę taką jak Netflix. Mają serwer uwierzytelniający, serwer strumieniowego przesyłania wideo i serwer rozliczeniowy. Gdyby korzystały z tradycyjnych sesji, każdy serwer musiałby stale komunikować się z centralną bazą danych, aby sprawdzić, czy użytkownik jest zalogowany.

W przypadku JWT serwer uwierzytelniania podpisuje token przy użyciu klucza prywatnego. Następnie użytkownik przekazuje ten token bezpośrednio do serwera wideo. Ponieważ serwer wideo posiada klucz publiczny, może samodzielnie zweryfikować podpis. Serwer wideo dokładnie wie, kim jest użytkownik, bez konieczności komunikowania się z serwerem uwierzytelniającym lub bazą danych. Umożliwia to nieograniczone skalowanie infrastruktury bez wąskich gardeł.

Ciemna strona: unieważnienie tokenu

JWT nie są idealne. Ich największa siła (bycie bezpaństwowcem) jest jednocześnie ich największą słabością. Ponieważ serwer nie prowadzi rejestru aktywnych tokenów, nie można łatwo wylogować użytkownika ani unieważnić konkretnego tokena przed jego wygaśnięciem.

Jeśli haker ukradnie token JWT użytkownika, będzie miał pełny dostęp do momentu wygaśnięcia znacznika czasu wygaśnięcia tokena. Aby ograniczyć to ryzyko, inżynierowie bezpieczeństwa stosują system dwóch tokenów:

• Tokeny dostępu: krótkotrwałe JWT (np. 15 minut) używane do żądań API.
• Odśwież tokeny: długotrwałe, stanowe tokeny przechowywane w bezpieczny sposób, używane wyłącznie do żądania nowych tokenów dostępu. Jeśli konto zostanie naruszone, serwer unieważni token odświeżania, a token dostępu hakera w naturalny sposób umrze w ciągu 15 minut.

Często zadawane pytania (FAQ)