Czytałem o uwierzytelnieniach i mylę się co do klasyfikacji typów.

Zacznijmy od uwierzytelniania opartego na plikach cookie. Jeśli dobrze to rozumiem, najważniejsze jest to, że wszystkie dane potrzebne do uwierzytelnienia użytkownika są przechowywane w plikach cookie. I to jest moje pierwsze zamieszanie: w ciasteczkach możemy przechowywać

• identyfikator sesji, a więc staje się uwierzytelnieniem opartym na sesji?
• roszczenia, a więc czy powinno się to nazywać uwierzytelnianiem opartym na roszczeniach?
• Odkryłem, że niektóre osoby przechowują nawet token JWT w plikach cookie, ale wydaje się to niestandardową implementacją własnego przepływu uwierzytelniania ...

Teraz przejdźmy do uwierzytelniania opartego na oświadczeniach. Głównym elementem jest roszczenie, a zbiór roszczeń można wykorzystać jako kontener

• pliki cookie (jak omówiono powyżej)
• token (JWT jako przykład).

Z drugiej strony, gdy mówimy o tokenie, może on zawierać dowolne informacje ... na przykład identyfikator sesji ...

Więc co przegapiłem? Dlaczego ludzie nie definiują czegoś podobnego Cookie-Session-basedlub Token-Claims-baseduwierzytelnienia, mówiąc o typach uwierzytelnień?

Zgadzam się, że nazywanie różnych pojęć jest mylące. Mówiąc o uwierzytelnianiu w kontekście sieciowym, należy wziąć pod uwagę kilka aspektów.

Jakie informacje wysyła klient podczas uwierzytelniania?

• Identyfikator sesji . Oznacza to, że serwer ma pamięć sesji, która zawiera aktywne sesje. Sesje są stanowe po stronie serwera.
• Zestaw roszczeń . Roszczenia zawierają informacje o tym, jakie operacje może wykonać klient. Serwer nie śledzi każdego uwierzytelnionego klienta, ale ufa roszczeniom. Roszczenia są zazwyczaj bezstanowe po stronie serwera.

W jaki sposób klient wysyła informacje uwierzytelniające?

• Cookies . Przeglądarki wysyłają pliki cookie automatycznie przy każdym żądaniu, po ustawieniu pliku cookie. Pliki cookie są wrażliwe na XSRF.
• Inne nagłówki . Zazwyczaj do tego celu wykorzystywany jest nagłówek autoryzacji. Nagłówki te nie są wysyłane automatycznie przez przeglądarkę, ale muszą zostać ustawione przez klienta. Jest to podatne na atak XSS.
• URL żądania . Informacje uwierzytelniające są zawarte w adresie URL. To nie jest powszechnie używane.

Jaki jest format informacji uwierzytelniających?

• Zwykły, niepodpisany tekst . Można tego użyć w przypadku identyfikatorów sesji. Identyfikator sesji generalnie nie jest zgadywalny przez klienta, więc serwer może ufać, że klient go nie podrobił.
• Json Web Token . JWT są podpisane kryptograficznie i zawierają informacje o wygaśnięciu. Klient zwykle może odkodować token, ale nie może go zmienić bez powiadomienia serwera.
• Dowolny inny podpisany format . Taki sam jak JWT. Ważną rzeczą jest podpis kryptograficzny, który zapobiega zmianie danych przez klienta.

Premia: w jaki sposób klient przechowuje informacje lokalnie

• Cookies . Dzieje się tak oczywiście w przypadku korzystania z plików cookie do przesyłania informacji. Ale pliki cookie mogą być również wykorzystywane jako mechanizm przechowywania po stronie klienta. Wymaga to, aby plik cookie był czytelny ze skryptów, aby był użyteczny. Na przykład klient może odczytać plik cookie za pomocą JavaScript i wysłać informacje za pomocą nagłówka autoryzacji.
• Lokalna pamięć masowa . Jest to często jedyna możliwa metoda, jeśli pliki cookie są niedostępne. Wymaga zarządzania za pomocą JavaScript.

Co ludzie mają na myśli, gdy mówią ...

• „Uwierzytelnianie na podstawie plików cookie” . Uważam, że zwykle oznacza to „Identyfikator sesji, wysyłany przez plik cookie, możliwy jako zwykły tekst”.
• „Uwierzytelnianie oparte na tokenach” . Zwykle oznacza to „Roszczenia, wysyłaj przy użyciu nagłówka uwierzytelniania, zakodowanego jako token Json Web”.
• „Uwierzytelnianie na podstawie oświadczeń” . Może to być dowolny identyfikator sesji.

Po prostu,

1. Uwierzytelnianie na podstawie plików cookie

   • Klient sieciowy (np. Przeglądarka internetowa) przechowuje pliki cookie wysłane przez serwer sieciowy po udanym uwierzytelnieniu.
   • Plik cookie zawiera informacje o użytkowniku, kliencie, sygnaturze czasowej authN i inne przydatne dane z unikalnym identyfikatorem w celu ustalenia pliku cookie.
   • Zazwyczaj pliki cookie są szyfrowane przez serwer WWW z ustawionym atrybutem domeny (np . google.com:) i przesyłane do klienta WWW.
   • Ilekroć klient sieciowy chce uzyskać dostęp do zasobu domeny (np . mail.google.com:), wysyła wszystkie pliki cookie na podstawie swojej domeny (np . google.com:) do serwera WWW, który sprawdza / weryfikuje i udziela / odmawia dostępu na podstawie stanu i znacznika czasu ciastko.

2. Uwierzytelnianie na podstawie sesji

   • Wraz z plikiem cookie klienta WWW, jeśli serwer WWW przechowuje dane uwierzytelniające użytkownika w swoim zapleczu, będzie to nazywane uwierzytelnianiem opartym na sesji.
   • Jest to bardzo przydatne w przypadku jakiegokolwiek naruszenia, które klient internetowy uzyskał dostęp do systemu, w którym nie powinien uzyskać dostępu, a następnie z zaplecza sesja klienta internetowego może zostać odwołana przez administratora.

3. Uwierzytelnianie oparte na tokenach

   • Zasadniczo jest to wykorzystywane w scenariuszach innych niż klient WWW, w których nie ma możliwości przechowywania plików cookie po stronie klienta.
   • W związku z tym serwer internetowy wysyła do klienta podpisany token (zawierający informacje o użytkowniku, kliencie, sygnaturze czasowej authN i inne przydatne dane o unikalnym identyfikatorze) po udanym uwierzytelnieniu.
   • Ilekroć klient chce uzyskać dostęp do zasobu, musi wysłać ten token, a serwer WWW sprawdza / weryfikuje token, zanim pozwoli na dostęp do zasobu.

4. Uwierzytelnianie na podstawie oświadczeń

   • Jest to to samo, co uwierzytelnianie oparte na tokenach, tyle że dodaje do tokena więcej danych o kliencie i / lub użytkowniku powiązanym z klientem.
   • Dane te dotyczą autoryzacji, która mówi o tym, co klient powinien zrobić w ramach zasobu (np. Mail.read, mail.delete, calendar.read).