cookie vs. sesja vs jwt

Czytam o uwierzytelnianiu / autoryzacji w aplikacjach internetowych. Czy ktoś może potwierdzić / poprawić moją obecną wiedzę?

• Pliki cookie: we wczesnej wersji plik tekstowy z unikalnym klientem zawiera wszystkie inne informacje potrzebne na temat klienta (np. Role)

• Sesja: w pliku wysyłany jest tylko unikalny identyfikator klienta (zwany także ciasteczkiem), wszystko inne jest przechowywane na serwerze

• JWT: wszystko jest przechowywane w tokenie (który może być również zapisany w pliku tekstowym, który jest również nazywany plikiem cookie)

Dziękujemy za wszelkie opinie!

Pliki cookie: we wczesnej wersji plik tekstowy z unikalnym klientem zawiera wszystkie inne informacje potrzebne na temat klienta (np. Role)

Pliki cookie to krotki key-valuepierwotnie adresowane w celu zachowania danych związanych z aktywnością klienta. To przechowywanie nazywamy stanem sesji lub aplikacji . Zasadniczo zostały stworzone do utrzymywania stanu aplikacji internetowych; dokładniej, stan po stronie klienta. ⁽¹⁾

Pliki cookie są zazwyczaj ustawiane przez serwer za pomocą nagłówków odpowiedzi ( Set-Cookie key=value). Mogą być jednak również ustawione przez klienta. Na przykład przez DOM ( document.cookie).

Jedną ważną rzeczą, którą należy wiedzieć o plikach cookie, jest to, że nie identyfikują one użytkowników. Raczej kojarzą one dane terna - klient - serwer / ścieżka . ⁽³⁾

Zazwyczaj kojarzymy pliki cookie z plikami, ponieważ w pierwszych dniach przeglądarek internetowych musiały one jakoś utrwalać pliki cookie, ponieważ są to najbardziej realne wsparcie. Dzisiejsze przeglądarki przechowują pliki cookie (między innymi) w lokalnych magazynach (wbudowane bazy danych).

Sesja: w pliku wysyłany jest tylko unikalny identyfikator klienta (zwany także ciasteczkiem), wszystko inne jest przechowywane na serwerze.

Według sesji masz na myśli sesje serwera . Jak skomentowałem, sesje mogą być realizowane także po stronie klienta. Różnica w przypadku sesji po stronie klienta polega na tym, że dane są przechowywane gdzieś po stronie serwera. ⁽²⁾ W takich scenariuszach otrzymujemy identyfikator sesji; i otrzymujemy to w postaci pliku cookie. Bez identyfikatora sesji serwer nie byłby w stanie skorelować przychodzących żądań z poprzednią aktywnością klienta. (3) Na przykład uwierzytelniony użytkownik, koszyk itp.

W każdym razie identyfikator sesji niekoniecznie identyfikuje użytkownika. Kojarzy określony stan aplikacji z klientem sieciowym. Sesje mogą zawierać dane użytkownika lub nie.

W aplikacjach rozproszonych sesja powinna być możliwa do serializacji z oczywistych powodów. Jeśli są przechowywane w pamięci, pamięć (komponent) w pamięci powinna być możliwa do serializacji. Częstym rozwiązaniem jest przechowywanie sesji w plikach. Lub w NoSQL DB, takim jak Redis.

Jeśli chodzi o bezpieczeństwo. Sesje po stronie serwera są bezpieczniejsze niż po stronie klienta. Klienci są bardziej podatni na zagrożenia, ponieważ użytkownicy zwykle nie są świadomi tylu zagrożeń, na jakie są narażeni. Przynajmniej nie zwykły użytkownik.

Z drugiej strony atakowanie infrastruktury po stronie serwera nie jest trywialne.

JWT: wszystko jest przechowywane w tokenie (który może być również zapisany w pliku tekstowym, który jest również nazywany plikiem cookie)

Nie całkiem. JWT przechowuje dane związane głównie z autoryzacją i wydawcą tokena.

Chociaż używają do przechowywania identyfikatora użytkownika (podrzędnego), znajdujemy JWT, które nie identyfikują uwierzytelnionych użytkowników. Na przykład tokeny do sesji gości. Główną treść JWT stanowią roszczenia ; elementy do sprawdzenia w procesie autoryzacji.

Należy pamiętać, że JWT nie są magazynami globalnymi . Sesja lub stan aplikacja wciąż musi być gdzieś przechowywane i zarządzane w sposób niezależny.

Jeśli chodzi o JWT, są one często przechowywane jako pliki cookie, chociaż mogą być również przechowywane w lokalnych magazynach. Ponadto społeczność OWASP uważa, że sessionStorage jest bezpieczniejsze dla przeglądarek internetowych. Jednak to zależy od wersji przeglądarki .

1: World Wide Web ma być bezpaństwowcem. Jeśli chcemy budować bezstanowe aplikacje po stronie serwera, sesje powinny być przechowywane gdzieś po stronie klienta.

2: Przekształcanie aplikacji po stronie serwera w aplikację stanową .

3: Klient jako aplikacja, a nie jako użytkownik.

Pliki cookie: we wczesnej wersji plik tekstowy z unikalnym klientem zawiera wszystkie inne informacje potrzebne na temat klienta (np. Role)

Twoja definicja pliku cookie tak naprawdę nie opisuje tego, co robią. Plik cookie to para klucz-wartość, która jest ustawiana za pomocą nagłówka odpowiedzi HTTP ( Set-Cookie) przez serwer i przechowywana przez klientów, którzy je obsługują. Pliki cookie są odsyłane z każdym kolejnym żądaniem (w Cookienagłówku) w celu dopasowania schematów, hosta, ścieżki, https, dopóki plik cookie nie wygasł. W pliku cookie możesz przechowywać wszystko, co chcesz, i pozwala ono obsługiwać stan w bezstanowym protokole HTTP.

Przykładowa wymiana plików cookie wygląda następująco:

Sesja: w pliku wysyłany jest tylko unikalny identyfikator klienta (zwany także ciasteczkiem), wszystko inne jest przechowywane na serwerze

Racja. Sesja to dane przechowywane po stronie serwera na temat bieżącej sesji użytkownika. Aby to działało w protokole bezstanowym, takim jak HTTP, użytkownik musi wysyłać swój identyfikator sesji przy każdym żądaniu, aby serwer mógł pobrać poprawną sesję dla użytkownika. Identyfikator sesji jest zwykle przechowywany w pliku cookie (patrz wyżej). To nie jest inny plik cookie niż jakikolwiek inny plik cookie, dane to tylko identyfikator serwera dla sesji użytkownika.

JWT: wszystko jest przechowywane w tokenie (który może być również zapisany w pliku tekstowym, który jest również nazywany plikiem cookie)

To prawie prawda. Wszystko jest przechowywane w tokenie. Token może być przechowywany w pliku cookie (patrz wyżej). Jest to alternatywa dla sesji serwera i działa, ponieważ token jest podpisany i zweryfikowany przez serwer, więc nie można go zmienić ani sfałszować, a przechowywanie po stronie klienta jest bezpieczne.