Skąd po zalogowaniu serwer wie, że każde późniejsze żądanie rzeczywiście pochodzi od Ciebie? Jedną z popularnych odpowiedzi jest Token sieciowy JSON, czyli JWT, zwykle wymawiany jako „jot”. Jest to mały, podpisany fragment danych, który klient wysyła przy każdym żądaniu, a serwer może go sprawdzić bez konieczności dotykania bazy danych.

Najszybszym sposobem zrozumienia JWT jest zbudowanie go, a następnie próba jego złamania. Zrobiliśmy to, używając tylko standardowej biblioteki Pythona w Pythonie 3.13, a poniższe dane wyjściowe pochodzą z tego uruchomienia. Ten kod służy do nauki. W prawdziwej aplikacji korzystaj z dobrze utrzymanej biblioteki, ponieważ szczegóły weryfikacji łatwo jest pomylić.

Co to jest JWT?

JWT to otwarty standard zdefiniowany w RFC 7519, służący do przekazywania roszczeń między dwiema stronami w postaci zwartego ciągu znaków. Roszczenie to po prostu stwierdzenie, np. „ID tego użytkownika to 42”. Ponieważ token jest podpisany, odbiorca może potwierdzić, kto go wydał i że nikt go nie zmieniał.

Pomyśl o opasce festiwalowej. Obsługa na bramce raz sprawdzi Twój bilet i wręczy Ci opaskę, którą trudno podrobić. Potem każde stoisko po prostu patrzy na zespół, bez konieczności dzwonienia do kasy. JWT działa w podobny sposób w przypadku interfejsu API.

Jak działa logowanie JWT

1. Użytkownik wysyła nazwę użytkownika i hasło do punktu końcowego logowania.
2. Serwer je sprawdza i tworzy podpisany token.
3. Klient przechowuje token.
4. Każde późniejsze żądanie zawiera je, zazwyczaj w nagłówku: Authorization: Bearer <token>.
5. Serwer weryfikuje podpis i wygaśnięcie, a następnie odczytuje oświadczenia.

Główną zaletą jest krok 5. Serwer nie musi wyszukiwać sesji, co jest wygodne, gdy wiele usług lub serwerów musi sprawdzać ten sam token. Jeśli dopiero zaczynasz korzystać z interfejsów API, zacznij od czym jest interfejs API.

Trzy części JWT

JWT wygląda jak losowy tekst, ale składa się z trzech sekcji zakodowanych w formacie Base64URL oddzielonych kropkami. Oto jeden, który wygenerowaliśmy:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzkzNTAwMDAwLCJleHAiOjE3OTM1MDA5MDB9
.7YfUDH_T-iDh8bMmUT8mmKYwOstzT8Ty--DTTAmQGWM

Dodaliśmy podziały wierszy, aby ułatwić czytanie. Dekodowanie pierwszych dwóch części daje zwykły JSON:

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"42","role":"user","iat":1793500000,"exp":1793500900}

Standardowe roszczenia

Możesz także dodać oświadczenia niestandardowe, takie jak role. Czasy to uniksowe znaczniki czasu wyrażone w sekundach. Utrzymuj niewielki ładunek, ponieważ token jest przesyłany z każdym żądaniem.

Zbuduj taki sam

Utworzenie tokena polega na zakodowaniu dwóch części JSON, a następnie podpisaniu ich kluczem tajnym przy użyciu HMAC-SHA256:

import base64, hashlib, hmac, json

SECRET = b"demo-secret-do-not-use-in-production"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(message):
    return b64url(hmac.new(SECRET, message.encode(), hashlib.sha256).digest())

def create_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    parts = [
        b64url(json.dumps(header, separators=(",", ":")).encode()),
        b64url(json.dumps(payload, separators=(",", ":")).encode()),
    ]
    message = ".".join(parts)
    return message + "." + sign(message)

Weryfikacja polega na ponownym przeliczeniu podpisu i porównaniu go z tym, który znajduje się w tokenie. Tylko ktoś znający sekret może stworzyć pasujący:

def verify_token(token, now):
    header, payload, signature = token.split(".")
    expected = sign(header + "." + payload)
    if not hmac.compare_digest(signature, expected):
        raise ValueError("bad signature")
    claims = json.loads(b64url_decode(payload))
    if claims["exp"] < now:
        raise ValueError("token expired")
    return claims

Prawidłowy token zwrócił swoje oświadczenia zgodnie z oczekiwaniami. compare_digest jest używany, ponieważ działa w stałym czasie, co pozwala uniknąć wycieku informacji w wyniku różnic taktowania.

Spróbuj to pokombinować

Załóżmy, że atakujący dekoduje ładunek, zmienia "role":"user" na "role":"admin", koduje go ponownie i zachowuje stary podpis. Próbowaliśmy tego wraz z dwoma innymi atakami:

Ta ostatnia próba jest wymierzona w prawdziwą historyczną słabość. Niektóre biblioteki kiedyś ufały własnemu nagłówkowi tokena, więc osoba atakująca mogła po prostu zadeklarować, że podpis nie jest potrzebny. Nasz kod zawsze wykorzystuje jeden ustalony algorytm, dlatego został odrzucony. W prawdziwej bibliotece zawsze określaj akceptowane algorytmy.

Podpisano, nie zaszyfrowano

Jest to najbardziej źle rozumiany punkt dotyczący JWT. Nasz sfałszowany token został odrzucony, a mimo to jego treść była w dalszym ciągu doskonale czytelna:

{"sub":"42","role":"admin","iat":1793500000,"exp":1793500900}

Base64URL to kodowanie, a nie szyfrowanie i każdy może to odwrócić bez żadnego klucza. Podpis uniemożliwia ludziom zmianę danych, ale nie pozwala na ich czytanie. Dlatego nigdy nie umieszczaj haseł, numerów kart ani prywatnych danych osobowych w ładunku JWT. Jeśli zawartość musi być ukryta, użyj zaszyfrowanych tokenów (JWE) lub po prostu przechowuj dane na serwerze.

HS256 kontra RS256

Dzięki podpisowi asymetrycznemu inne usługi mogą weryfikować tokeny bez możliwości wybicia własnych, co ogranicza szkody w przypadku naruszenia bezpieczeństwa jednego z nich.

JWT vs sesje

JWT są często przedstawiane jako nowoczesny zamiennik sesji. W rzeczywistości każdy ma kompromisy:

W przypadku tradycyjnej witryny internetowej renderowanej przez serwer plik cookie sesji jest często prostszy i bezpieczniejszy. JWT mają większy sens w przypadku interfejsów API używanych przez kilka usług lub dla klientów mobilnych.

Gdzie przechowywać tokeny w przeglądarce

Wiele przewodników bezpieczeństwa faworyzuje HttpOnly, Secure, SameSite pliki cookie dla aplikacji internetowych. Niezależnie od tego, którą opcję wybierzesz, zawsze używaj protokołu HTTPS. Aby wysłać token z JavaScript, zobacz nasz samouczek API JavaScript Fetch.

Odśwież tokeny

Krótki okres ważności ogranicza szkody spowodowane skradzionym tokenem, ale nikt nie chce logować się co 15 minut. Zwykłe rozwiązanie wykorzystuje dwa tokeny:

• Token dostępu: krótkotrwały, np. minuty, wysyłany z każdym żądaniem API.
• Odśwież token: trwalszy, przechowywany ostrożniej i używany wyłącznie w celu uzyskania nowych tokenów dostępu.

Serwer śledzi tokeny odświeżania, dzięki czemu może je unieważnić, co daje praktyczne wylogowanie. Obracanie ich przy każdym użyciu pomaga również wykryć kradzież, ponieważ skradziony stary token zostaje odtworzony.

Typowe błędy bezpieczeństwa

• Dekodowanie bez weryfikacji. Odczytanie ładunku nie czyni go wiarygodnym. Zawsze sprawdzaj podpis.
• Akceptowanie dowolnego algorytmu. Ustaw jawną listę dozwolonych algorytmów.
• Używanie słabego sekretu. Krótkie sekrety można złamać offline. Użyj długiej wartości losowej i trzymaj ją poza kontrolą źródła.
• Pomijanie wygaśnięcia. Tokeny z numerem exp mogą działać wiecznie w przypadku kradzieży.
• Nie sprawdzam iss i aud. W przeciwnym razie token wydany dla jednej usługi może zostać zaakceptowany przez inną.
• Ufanie nieaktualnym oświadczeniom. Rola w tokenie może być nieaktualna, dopóki nie wygaśnie.
• Tokeny rejestrowania. Każdy, kto czyta Twoje logi, może je ponownie wykorzystać.
• Nie testuję ścieżek błędów. Dodaj testy dla tokenów, które wygasły i zmodyfikowały, a także ważnych. Pomocny może być nasz przewodnik testowanie API za pomocą Postmana.

Podsumowanie

JWT to podpisane dane, którym serwer może zaufać bez wyszukiwania, a nie tajny kontener i nie automatyczna aktualizacja w trakcie sesji. Korzystaj z krótkiego wygaśnięcia, sprawdzaj wszystko za pomocą utrzymywanej biblioteki i trzymaj prywatne dane poza ładunkiem. Aby się o tym przekonać, uruchom mały skrypt taki jak nasz, zmień jeden znak tokena i zobacz, jak weryfikacja kończy się niepowodzeniem.

Najczęstsze pytania

Ucz się dalej