Czytałem kilka postów na temat „JWT vs Cookie”, ale tylko mnie wprawiły w zakłopotanie ...

1. Chcę wyjaśnienia , kiedy ludzie mówią o „uwierzytelnianiu opartym na tokenach a pliki cookie”, pliki cookie odnoszą się tutaj jedynie do plików cookie sesji ? Rozumiem, że plik cookie jest jak medium , może być używany do implementacji uwierzytelniania opartego na tokenach (przechowywać coś, co może identyfikować zalogowanego użytkownika po stronie klienta ) lub uwierzytelniania opartego na sesji (przechowywać stałą po stronie klienta pasujące do informacji o sesji po stronie serwera )

2. Dlaczego potrzebujemy tokena internetowego JSON ? Używałem standardowego pliku cookie do zaimplementowania uwierzytelniania opartego na tokenach ( nie używam identyfikatora sesji, nie używam pamięci serwera ani przechowywania plików ) Set-Cookie: user=innocent; preferred-color=azure:, a jedyną różnicą, jaką zauważyłem, jest to, że JWT zawiera zarówno ładunek, jak i podpis ... podczas gdy możesz wybrać między plikiem cookie ze podpisem a zwykłym tekstem dla nagłówka http. Moim zdaniem podpisany plik cookie ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') jest bardziej wydajny, jedyną wadą jest to, że klient nie może odczytać tokena, tylko serwer może ... ale myślę, że jest w porządku, ponieważ tak jak żądanie w JWT jest opcjonalne, nie jest konieczne, aby token mieć znaczenie

Największą różnicą między tokenami okaziciela a plikami cookie jest to, że przeglądarka automatycznie wysyła pliki cookie , przy czym tokeny okaziciela muszą być jawnie dodane do żądania HTTP.

Ta funkcja sprawia, że ​​pliki cookie są dobrym sposobem zabezpieczania witryn internetowych, w których użytkownik loguje się i nawiguje między stronami za pomocą łączy.

Przeglądarka automatycznie wysyłająca pliki cookie ma również duży minus, którym są ataki CSRF . W ataku CSRF złośliwa witryna wykorzystuje fakt, że Twoja przeglądarka automatycznie dołącza uwierzytelniające pliki cookie do żądań wysyłanych do tej domeny i nakłania Twoją przeglądarkę do wykonania żądania.

Załóżmy, że witryna internetowa pod adresem https://www.example.com umożliwia uwierzytelnionym użytkownikom zmianę ich haseł przez POSTwprowadzenie nowego hasła na https://www.example.com/changepassword bez konieczności umieszczania nazwy użytkownika lub starego hasła.

Jeśli nadal jesteś zalogowany w tej witrynie, gdy odwiedzasz złośliwą witrynę, która ładuje stronę w Twojej przeglądarce, która uruchamia POST na ten adres, Twoja przeglądarka wiernie dołączy pliki cookie uwierzytelniania, umożliwiając atakującemu zmianę hasła.

Pliki cookie mogą być również używane do ochrony usług internetowych, ale obecnie najczęściej używane są tokeny na okaziciela. Jeśli używasz plików cookie do ochrony swojej usługi internetowej, usługa ta musi działać w domenie, dla której ustawiono pliki cookie uwierzytelniania, ponieważ zasady tego samego pochodzenia nie wysyłają plików cookie do innej domeny.

Ponadto pliki cookie utrudniają korzystanie z interfejsu API aplikacjom innym niż przeglądarki (takim jak aplikacje mobilne na tablety).

Przegląd

To, o co prosisz, to różnica między plikami cookie a tokenami okaziciela do wysyłania tokenów sieci Web JSON (JWT) z klienta na serwer.

Zarówno pliki cookie, jak i tokeny okaziciela wysyłają dane.

Jedna różnica polega na tym, że pliki cookie służą do wysyłania i przechowywania dowolnych danych, podczas gdy tokeny okaziciela służą do wysyłania danych autoryzacyjnych.

Te dane są często kodowane jako token JWT.

Ciastko

Plik cookie to para nazwa-wartość, która jest przechowywana w przeglądarce internetowej i ma datę ważności i powiązaną domenę.

Przechowujemy pliki cookie w przeglądarce internetowej z JavaScriptem lub z nagłówkiem odpowiedzi HTTP.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Przeglądarka internetowa automatycznie wysyła pliki cookie z każdym żądaniem do domeny pliku cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Token okaziciela

Token okaziciela to wartość umieszczana w Authorizationnagłówku każdego żądania HTTP. Nie jest nigdzie automatycznie zapisywany, nie ma daty wygaśnięcia ani powiązanej domeny. To tylko wartość. Ręcznie przechowujemy tę wartość w naszych klientach i ręcznie dodajemy tę wartość do nagłówka autoryzacji HTTP.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT i uwierzytelnianie oparte Reklamowe

Kiedy wykonujemy uwierzytelnianie oparte na tokenach, takie jak OpenID, OAuth lub OpenID Connect, otrzymujemy access_token (a czasem id_token) od zaufanego organu. Zwykle chcemy go przechowywać i wysyłać wraz z żądaniami HTTP dotyczącymi chronionych zasobów. Jak to zrobimy?

Opcja 1 to przechowywanie tokena (ów) w pliku cookie. To obsługuje przechowywanie, a także automatycznie wysyła token (y) do serwera w Cookienagłówku każdego żądania. Następnie serwer analizuje plik cookie, sprawdza token (y) i odpowiednio odpowiada.

Inną opcją jest przechowywanie tokenu w pamięci lokalnej / sesji, a następnie ręczne ustawienie Authorizationnagłówka każdego żądania. W takim przypadku serwer odczytuje nagłówek i postępuje tak, jak w przypadku pliku cookie.

Warto przeczytać powiązane RFC, aby dowiedzieć się więcej.

Oprócz tego, co powiedział MvdD o automatycznym wysyłaniu plików cookie:

1. Plik cookie może być medium, ale jego najważniejszą funkcją jest sposób interakcji z przeglądarką. Pliki cookie są ustawiane przez serwer i wysyłane w żądaniach w bardzo specyficzny sposób. Z drugiej strony JWT jest wyłącznie medium, jest stwierdzeniem pewnych faktów w określonej strukturze. Gdybyś miał taką ochotę, mógłbyś umieścić token JWT jako plik cookie uwierzytelniania. Kiedy czytasz artykuły porównujące je, zwykle mówią o używaniu tokena JWT wysłanego jako token okaziciela przez kod frontonu w porównaniu z plikiem cookie uwierzytelniania, który odpowiada pewnej sesji buforowanej lub danych użytkownika na zapleczu.
2. JWT oferuje wiele funkcji i umieszcza je w standardzie, dzięki czemu mogą być używane między stronami. JWT może działać jako podpisane potwierdzenie pewnych faktów w wielu różnych miejscach. Plik cookie, bez względu na to, jakie dane w nim umieścisz lub czy go podpiszesz, ma sens tylko wtedy, gdy jest używany między przeglądarką a określonym zapleczem. JWT może być używany od przeglądarki do zaplecza, między zapleczem kontrolowanym przez różne strony (przykładem jest OpenId Connect) lub w ramach usług zaplecza jednej strony. Jeśli chodzi o Twój konkretny przykład podpisanych plików cookie, prawdopodobnie możesz osiągnąć te same funkcje („nie używaj identyfikatora sesji, nie używaj pamięci serwera ani przechowywania plików”), co JWT w tym przypadku, ale tracisz na bibliotekach i recenzjach standard, oprócz kwestii CSRF, o których mowa w drugiej odpowiedzi.

Podsumowując: posty, które czytasz, prawdopodobnie porównują JWT jako token okaziciela z plikiem cookie uwierzytelniania dla celów uwierzytelniania przeglądarki i serwera. Ale JWT może zrobić znacznie więcej, wprowadza standaryzację i funkcje do użytku poza przypadkiem użycia, o którym prawdopodobnie myślisz.

Chociaż pliki cookie mogą zwiększać ryzyko ataków CSRF, ponieważ są wysyłane automatycznie wraz z żądaniami, mogą zmniejszyć ryzyko ataków XSS, gdy HttpOnlyflaga jest ustawiona, ponieważ żaden skrypt, który jest wstrzykiwany na stronę, nie będzie w stanie odczytać ciastko.

CSRF: użytkownik klika łącze (lub wyświetla obrazy) w witrynie atakującego, co powoduje, że przeglądarka wysyła żądanie do witryny ofiary. Jeśli ofiara używa plików cookie, przeglądarka automatycznie umieści plik cookie w żądaniu, a jeśli żądanie GET może spowodować jakiekolwiek działania nie tylko do odczytu, strona ofiary jest narażona na atak.

XSS: osoba atakująca osadza skrypt w witrynie ofiary (witryna ofiary jest podatna na ataki tylko wtedy, gdy dane wejściowe nie są prawidłowo oczyszczone), a skrypt atakującego może zrobić wszystko, na co zezwala javascript na stronie. Jeśli przechowujesz tokeny JWT w pamięci lokalnej, skrypt atakującego może odczytać te tokeny, a także wysłać je do kontrolowanego przez siebie serwera. Jeśli używasz plików cookie z HttpOnlyflagą, skrypt atakującego nie będzie w stanie odczytać Twojego pliku cookie. To powiedziawszy, skrypt, który pomyślnie wstrzyknął, nadal będzie w stanie zrobić wszystko, co może zrobić javascript, więc nadal masz połączenie z IMO (tj. Podczas gdy mogą nie być w stanie odczytać pliku cookie, aby wysłać go na własny serwer do późniejszego użytku , mogą wysyłać żądania do najbliższej witryny za pomocą XHR, który i tak będzie zawierał plik cookie).

Ref - potrzeba JSON Web Token

Ciasteczka

W przypadku plików cookie, gdy użytkownik zostanie uwierzytelniony, serwer Gmail utworzy unikalny identyfikator sesji. Odpowiadając temu identyfikatorowi sesji, będzie przechowywać w pamięci wszystkie informacje o użytkowniku, które są potrzebne serwerowi Gmaila do rozpoznania użytkownika i umożliwienia mu wykonywania operacji.
Również wtedy dla wszystkich kolejnych żądań i odpowiedzi ten identyfikator sesji również zostanie przekazany. Więc teraz, gdy serwer otrzyma żądanie, sprawdzi identyfikator sesji. Użycie tego identyfikatora sesji sprawdzi, czy są jakieś odpowiednie informacje. Pozwoli to użytkownikowi uzyskać dostęp do zasobu i zwrócić odpowiedź wraz z identyfikatorem sesji.

Wady plików cookie

• Pliki cookie / identyfikator sesji nie są niezależne. To jest token referencyjny. Podczas każdej weryfikacji serwer Gmaila musi pobrać odpowiadające mu informacje.
• Nie nadaje się do architektury mikrousług obejmującej wiele interfejsów API i serwerów

JWT

• JWT jest samowystarczalny. To symbol wartości. Tak więc podczas każdej weryfikacji serwer Gmail nie musi pobierać odpowiednich informacji.
• Jest podpisany cyfrowo, więc jeśli ktoś go zmodyfikuje, serwer będzie o tym wiedział
• Jest najbardziej odpowiedni dla architektury mikrousług
• Ma inne zalety, takie jak określenie czasu wygaśnięcia.