JSON Web Token (JWT)

JSON Web Token, w skrócie JWT, jest standardowym formatem tokenu do przekazywania zestawu deklaracji, czyli claims, między stronami. RFC 7519 definiuje JWT jako kompaktowy i bezpieczny dla URL sposób reprezentowania takich informacji. W praktyce token bywa ciągiem trzech części oddzielonych kropkami: nagłówka, ładunku i podpisu. Serwer lub automatyzacja może dzięki podpisowi sprawdzić, czy dane nie zostały zmienione po wystawieniu.

Ładunek JWT zwykle zawiera informacje takie jak issuer, czyli wystawca, subject, czyli podmiot, audience, czas wygaśnięcia oraz czas wystawienia. To dane potrzebne do decyzji, czy żądanie jest ważne i czego dotyczy. Istotne: standardowe JWT podpisane jako JWS nie szyfruje ładunku. Osoba mająca token może zwykle go odczytać po zakodowaniu Base64URL. Nie wpisuj więc do niego hasła, klucza API, pełnych danych klienta ani poufnego promptu.

JWT często pojawia się obok OAuth 2.0, ale te pojęcia nie są tym samym. OAuth opisuje delegowanie dostępu, np. zgodę użytkownika na połączenie aplikacji z kalendarzem. JWT jest formatem tokenu, który może, lecz nie musi, zostać użyty w takim przepływie. Zanim skonfigurujesz integrację, sprawdź dokumentację konkretnego dostawcy: token dostępu może być JWT, tokenem nieprzezroczystym albo innym poświadczeniem.

W systemie eksperta JWT ma sens, gdy własny endpoint, panel klienta albo webhook musi rozpoznać uprawnioną aplikację. Przykładowo formularz po autoryzacji wysyła żądanie do API z tokenem, a API weryfikuje podpis, wystawcę, odbiorcę i datę wygaśnięcia, zanim przekaże dane do workflowu AI. Sama obecność poprawnie wyglądającego tokenu nie jest dowodem zaufania. Odbiorca musi wykonać walidację kryptograficzną i kontrolę deklaracji.

Najczęstszy błąd to traktowanie dekodowania JWT jak weryfikacji. Odczytanie nagłówka i payloadu nie potwierdza podpisu. Nie wolno też akceptować algorytmu podanego przez nadawcę bez ograniczenia go po stronie serwera, ignorować exp, iss lub aud ani używać długo ważnych tokenów w linkach i logach. Token jest poświadczeniem. Jeśli wycieknie, atakujący może użyć go do czasu wygaśnięcia, o ile system nie ma dodatkowego mechanizmu unieważniania.

Praktyczny standard pracy: wydawaj tokeny o możliwie krótkim czasie życia, przechowuj sekrety podpisujące poza kodem, ogranicz zakres uprawnień i nie loguj całego nagłówka Authorization. W webhookach nie zakładaj, że JWT zastępuje podpis dostawcy, jeśli dostawca zaleca własną metodę weryfikacji. Dla każdej integracji zapisz: kto wystawia token, dla jakiej usługi jest przeznaczony, jaki algorytm akceptujesz i co dzieje się po wygaśnięciu lub błędzie walidacji.