Token sieciowy JSON — JSON Web Token

JSON Web Token ( JWT , wymawiane / dʒ ɒ t / , tak samo jak słowo „jot”) to proponowany standard internetowy do tworzenia danych z opcjonalnym podpisem i/lub opcjonalnym szyfrowaniem, którego ładunek przechowuje JSON, który potwierdza pewną liczbę roszczeń . Tokeny są podpisywane przy użyciu prywatnego klucza tajnego lub klucza publicznego/prywatnego .

Na przykład serwer może wygenerować token z oświadczeniem „zalogowany jako administrator” i przekazać go klientowi. Klient może następnie użyć tego tokena, aby udowodnić, że jest zalogowany jako administrator. Tokeny mogą być podpisane kluczem prywatnym jednej ze stron (zwykle serwera), dzięki czemu strona może następnie zweryfikować, czy token jest legalny. Jeśli druga strona, za pomocą odpowiednich i godnych zaufania środków, jest w posiadaniu odpowiedniego klucza publicznego, również jest w stanie zweryfikować legalność tokena. Te tokeny mają być zwarte, URL -safe, używane zwłaszcza w przeglądarki internetowej single-sign-on (SSO) kontekście. Oświadczenia JWT mogą zazwyczaj służyć do przekazywania tożsamości uwierzytelnionych użytkowników między dostawcą tożsamości a dostawcą usług lub dowolnego innego typu oświadczeń wymaganych przez procesy biznesowe.

JWT opiera się na innych standardach opartych na JSON : JSON Web Signature i JSON Web Encryption .

Struktura

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "loggedInAs": "admin",
  "iat": 1422779638
}

HMAC_SHA256(
  secret,
  base64urlEncoding(header) + '.' +
  base64urlEncoding(payload)
)

Te trzy części są zakodowane oddzielnie przy użyciu Base64url Encoding RFC  4648 i połączone przy użyciu kropek w celu utworzenia tokena JWT:

const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)

Powyższe dane oraz sekret „secretkey” tworzą token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8ZynFmSrNjCpyW

Ten wynikowy token można łatwo przekazać do HTML i HTTP .

Posługiwać się

Podczas uwierzytelniania, gdy użytkownik pomyślnie zaloguje się przy użyciu swoich poświadczeń, zostanie zwrócony token sieciowy JSON, który musi zostać zapisany lokalnie (zwykle w magazynie lokalnym lub sesyjnym , ale można również używać plików cookie ), zamiast tradycyjnego podejścia polegającego na tworzeniu sesji na serwerze i zwrócenie pliku cookie. W przypadku procesów nienadzorowanych klient może również uwierzytelnić się bezpośrednio, generując i podpisując własny token JWT za pomocą wstępnie udostępnionego klucza tajnego i przesyłając go do usługi zgodnej z OAuth , na przykład:

POST /oauth2/token?
Content-type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...

Jeśli klient przejdzie poprawną asercję JWT, serwer wygeneruje access_token ważny do wykonywania wywołań do aplikacji i przekaże go z powrotem do klienta:

{
  "access_token": "eyJhb...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Gdy klient chce uzyskać dostęp do chronionej trasy lub zasobu, agent użytkownika powinien wysłać token JWT, zwykle w Authorizationnagłówku przy użyciu Bearerschematu. Treść nagłówka może wyglądać tak:

Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI

Jest to mechanizm uwierzytelniania bezstanowego, ponieważ stan użytkownika nigdy nie jest zapisywany w pamięci serwera. Chronione trasy serwera będą sprawdzać, czy w nagłówku Authorization znajduje się prawidłowy token JWT, a jeśli jest obecny, użytkownik będzie mógł uzyskać dostęp do chronionych zasobów. Ponieważ tokeny JWT są samowystarczalne, dostępne są wszystkie niezbędne informacje, co zmniejsza potrzebę wielokrotnego wykonywania zapytań do bazy danych.

Pola standardowe

Realizacje

Implementacje JWT istnieją dla wielu języków i frameworków, w tym między innymi:

Luki

Tokeny internetowe JSON mogą zawierać stan sesji. Ale jeśli wymagania projektu zezwalają na unieważnianie sesji przed wygaśnięciem znacznika JWT, usługi nie mogą już ufać potwierdzeniom tokenu przez sam token. Aby sprawdzić, czy sesja przechowywana w tokenie nie została odwołana, należy sprawdzić asercje tokenu względem magazynu danych . To sprawia, że ​​tokeny nie są już bezstanowe, co podważa podstawową zaletę tokenów JWT.

Konsultant ds. bezpieczeństwa Tim McLean zgłosił luki w niektórych bibliotekach JWT, które wykorzystywały algpole do nieprawidłowego sprawdzania poprawności tokenów, najczęściej poprzez akceptację alg=nonetokena. Chociaż te luki zostały załatane, McLean zasugerował algcałkowite wycofanie tej dziedziny, aby zapobiec podobnym zamieszaniom w implementacji. Mimo alg=noneto na wolności wciąż znajdują się nowe luki w zabezpieczeniach, a przyczyną tego są cztery CVE złożone w okresie 2018-2021.

Przy odpowiednim projekcie programiści mogą wyeliminować luki w algorytmach, podejmując środki ostrożności:

1. Nigdy nie pozwól, aby sam nagłówek JWT sterował weryfikacją
2. Poznaj algorytmy (unikaj uzależnienia od samego algpola)
3. Użyj odpowiedniego rozmiaru klucza

Zobacz też

• Token dostępu

Bibliografia

Zewnętrzne linki

• RFC  7519
• jwt.io – wyspecjalizowana strona o JWT wraz z narzędziami i dokumentacją, utrzymywana przez Auth0
• Spring Boot JWT Auth – integracja uwierzytelniania JWT z frameworkiem Spring
• JWT Security – JWT Security e-Book PDF (język polski)
• Dlaczego potrzebujemy JWT we współczesnej sieci - szczegółowy artykuł na ten temat z pewnymi rozważaniami historycznymi