Token internetowy JSON

Token internetowy JSON
Skrót JWT
Status Proponowany standard
Opublikowane po raz pierwszy 28 grudnia 2010 ( 2010-12-28 )
Ostatnia wersja  
RFC 7519 maj 2015 r
Organizacja IETF
Komisja IEGS
Autorski
Normy bazowe
Domena Wymiana danych
Strona internetowa datatracker.ietf.org/doc/html/rfc7519 _ _ _ _ _

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 zawiera JSON potwierdzający pewną liczbę roszczeń . Tokeny są podpisywane przy użyciu klucza prywatnego lub klucza publicznego/prywatnego .

Na przykład serwer może wygenerować token z żądaniem „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), aby każda strona mogła później zweryfikować, czy token jest legalny. Jeśli druga strona, za pomocą odpowiednich i godnych zaufania środków, jest w posiadaniu odpowiedniego klucza publicznego, ona również jest w stanie zweryfikować legalność tokena. Tokeny , aby były kompaktowe, bezpieczne dla adresów URL i użyteczne zwłaszcza w kontekst pojedynczego logowania (SSO) w przeglądarce internetowej . 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

Nagłówek
Określa, który algorytm jest używany do generowania podpisu
HS256 wskazuje, że ten token jest podpisany przy użyciu HMAC-SHA256.
Typowe stosowane algorytmy kryptograficzne to HMAC z SHA-256 (HS256) oraz podpis RSA z SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 wprowadza znacznie więcej zarówno do uwierzytelniania, jak i szyfrowania. 

   
   
 {  "alg"  :  "HS256"  ,  "typ"  :  "JWT"  ​​}
Ładunek
Zawiera zestaw roszczeń. Specyfikacja JWT definiuje siedem zarejestrowanych nazw roszczeń, które są standardowe pola powszechnie zawarte w tokenach. W zależności od celu tokena zwykle uwzględniane są również oświadczenia niestandardowe.
Ten przykład ma standardowe oświadczenie wystawione w czasie ( iat ) i oświadczenie niestandardowe ( zalogowane ). 

   
   
 {  "loggedInAs"  :  "admin"  ,  "iat"  :  1422779638  }
Podpis
  Bezpiecznie sprawdza poprawność tokena. Podpis jest obliczany przez kodowanie nagłówka i ładunku przy użyciu Base64url Encoding RFC 4648 i połączenie tych dwóch razem z separatorem okresu. Ciąg ten jest następnie przepuszczany przez algorytm kryptograficzny określony w nagłówku. W tym przykładzie zastosowano algorytm HMAC-SHA256 ze wspólnym kluczem tajnym (zdefiniowano również algorytmy klucza publicznego). Kodowanie Base64url jest podobne do base64 , ale wykorzystuje inne znaki niealfanumeryczne i pomija dopełnienie. 

  
     
  
 HMAC_SHA256  (  tajne  ,  base64urlEncoding  (  nagłówek  )  +  '.'  +  base64urlEncoding  (  ładunek  )  )

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

            const  token  =  base64urlEncoding  (  nagłówek  )  +  '.'  +  base64urlEncoding  (  ładunek  )  +  '.'  +  base64urlEncoding  (  podpis  )

Powyższe dane oraz sekret "secretkey" tworzą token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

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

Używać

Podczas uwierzytelniania, gdy użytkownik pomyślnie zaloguje się przy użyciu swoich poświadczeń, token JSON Web Token zostanie zwrócony i musi zostać zapisany lokalnie (zwykle w pamięci lokalnej lub w pamięci sesji , ale można również użyć 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ą współdzielonego klucza tajnego i przekazując go do usługi OAuth w następujący sposób: 


 

 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 przekaże prawidłową asercję JWT, serwer wygeneruje token dostępu 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 nagłówku HTTP autoryzacji przy użyciu schematu okaziciela . Zawartość nagłówka może wyglądać następująco: 

 Autoryzacja: posiadacz eyJhbGci  ...<snip>...  yu5CSpyHI

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

Standardowe pola

Kod Nazwa Opis
Standardowe pola roszczeń Internetowe wersje robocze definiują następujące standardowe pola („oświadczenia”), których można użyć w zestawie oświadczeń JWT.
jest Emitent Identyfikuje podmiot, który wystawił token JWT.
pod Temat Identyfikuje temat JWT.
dźwięk Publiczność Identyfikuje odbiorców, dla których jest przeznaczony token JWT. Każdy zleceniodawca, który ma przetworzyć token JWT, musi identyfikować się z wartością w żądaniu odbiorców. Jeśli podmiot przetwarzający roszczenie nie identyfikuje się z wartością w aud , gdy to roszczenie jest obecne, JWT musi zostać odrzucony.
do potęgi Data ważności Określa czas wygaśnięcia, po którym token JWT nie może zostać zaakceptowany do przetwarzania. Wartość musi być typu NumericDate: liczbą całkowitą lub dziesiętną, reprezentującą sekundy po 1970-01-01 00:00:00Z .
nbf Nie przed Określa czas, w którym token JWT zacznie być akceptowany do przetwarzania. Wartość musi być typu NumericDate.
iat Wydana w Identyfikuje czas wystawienia tokenu JWT. Wartość musi być typu NumericDate.
jti Identyfikator JWT Unikalny identyfikator tokena uwzględniający wielkość liter, nawet wśród różnych emitentów.
Często używane pola nagłówka Następujące pola są często używane w nagłówku JWT
typ Typ tokena Jeśli jest obecny, musi być ustawiony na zarejestrowany typ nośnika IANA .
cty Typ zawartości Jeśli używane jest zagnieżdżone podpisywanie lub szyfrowanie, zaleca się ustawienie JWT ; w przeciwnym razie pomiń to pole.
alg Algorytm kodu uwierzytelniającego wiadomość Wystawca może dowolnie ustawić algorytm weryfikacji podpisu na tokenie. Jednak niektóre obsługiwane algorytmy są niepewne.
dziecko Identyfikator klucza Wskazówka wskazująca, którego klucza użył klient do wygenerowania podpisu tokenu. Serwer dopasuje tę wartość do klucza w pliku, aby zweryfikować, czy podpis jest ważny, a token jest autentyczny.
x5c x.509 Łańcuch certyfikatów Łańcuch certyfikatów w formacie RFC4945 odpowiadający kluczowi prywatnemu używanemu do generowania podpisu tokena. Serwer użyje tych informacji do sprawdzenia, czy podpis jest ważny, a token jest autentyczny.
x5u Adres URL łańcucha certyfikatów x.509 Adres URL, pod którym serwer może pobrać łańcuch certyfikatów odpowiadający kluczowi prywatnemu użytemu do wygenerowania podpisu tokena. Serwer pobierze i użyje tych informacji do zweryfikowania autentyczności podpisu.
krytykować Krytyczny Lista nagłówków, które serwer musi zrozumieć, aby zaakceptować token jako ważny
Kod Nazwa Opis

Implementacje

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

Luki w zabezpieczeniach

Tokeny internetowe JSON mogą zawierać stan sesji. Ale jeśli wymagania projektu zezwalają na unieważnienie sesji przed wygaśnięciem tokena JWT, usługi nie mogą już ufać potwierdzeniom tokena na podstawie samego tokena. Aby zweryfikować, czy sesja przechowywana w tokenie nie została odwołana, potwierdzenia tokenu muszą zostać porównane z magazynem danych . To sprawia, że ​​tokeny nie są już bezstanowe, co podważa podstawową zaletę JWT.

Konsultant ds. bezpieczeństwa Tim McLean zgłosił luki w zabezpieczeniach niektórych bibliotek JWT, które używały pola alg do nieprawidłowego sprawdzania poprawności tokenów, najczęściej poprzez akceptację tokena alg=none . Chociaż te luki zostały załatane, McLean zasugerował całkowite wycofanie alg , aby zapobiec podobnym zamieszaniu w implementacji. Mimo to nadal wykrywane są nowe luki alg=none , a cztery CVE zgłoszone w latach 2018-2021 miały tę przyczynę.

Dzięki odpowiedniemu projektowi programiści mogą wyeliminować luki w zabezpieczeniach algorytmu, podejmując środki ostrożności:

  1. Nigdy nie pozwól, aby sam nagłówek JWT kierował weryfikacją
  2. Znajomość algorytmów (unikaj zależności od samego pola alg )
  3. Użyj odpowiedniego rozmiaru klucza

Zobacz też

  •   RFC7519 _
  • jwt.io – specjalistyczna strona o JWT z narzędziami i dokumentacją, prowadzona przez Auth0
Pobrano z „ https://en.wikipedia.org/w/index.php?title=JSON_Web_Token&oldid=1140713249 ”