Wszyscy lubimy, że natywne aplikacje proszą o logowanie tylko raz, a potem pamiętają nas do momentu, gdy poprosimy o wylogowanie. Niestety internet nie zawsze działa w ten sposób.
Obecnie, gdy urządzenia, zwłaszcza mobilne, są bardziej osobiste, a coraz więcej witryn wysyła cały ruch przez HTTPS, co zmniejsza ryzyko kradzieży tokenów, właściciele witryn powinni ponownie przemyśleć swoje zasady dotyczące krótkotrwałych plików cookie i wprowadzić bardziej przyjazne użytkownikom sesje o dłuższym czasie trwania.
Jednak nawet jeśli chcesz, aby sesja trwała dłużej, niektóre witryny nie weryfikują uwierzytelniania użytkownika przy każdym żądaniu (czyli nie ma możliwości odwołania pliku cookie sesji po jego wydaniu). Zwykle prowadzi to do krótkich sesji, ponieważ użytkownik musi często logować się ponownie, aby można było ponownie zweryfikować jego uwierzytelnianie. Pozwala to na anulowanie istniejących sesji po upływie określonego czasu, np. w przypadku zmiany hasła.
Jeśli to Twoje podejście, mamy rozwiązanie techniczne, które może Ci pomóc w automatycznym ponownym sprawdzaniu pliku cookie uwierzytelniania bezstanowego. Polega ono na tym, że mamy dodatkowy długotrwały token, który można wykorzystać do odświeżenia istniejącego krótkotrwałego pliku cookie uwierzytelniania. Wykorzystanie nowego wzorca usługi dla usług działających w tle pozwala nam regularnie „sprawdzać” token długoterminowy, weryfikować uwierzytelnianie użytkownika (np. sprawdzać, czy nie zmienił on ostatnio hasła lub nie anulował sesji w inny sposób) i wydawać nowe krótkotrwałe pliki cookie uwierzytelniania.
praktyczna propozycja przejścia na bezpieczne długie sesje w internecie;
W tym poście opisujemy nową metodę, którą proponujemy, zwaną 2-Cookie-Handoff (2CH). Mamy nadzieję, że ten artykuł pomoże nam uzyskać opinie społeczności na temat tego, czy takie podejście wydaje się odpowiednie, a jeśli tak, to pomoże nam współpracować z branżą nad udokumentowaniem sprawdzonych metod korzystania z 2CH.
Service worker to nowa technologia obsługiwana przez wiele przeglądarek, takich jak Chrome, Firefox, Opera, a wkrótce także Edge. Umożliwiają przechwytywanie wszystkich żądań sieci z witryny za pomocą wspólnego punktu kodu na kliencie bez modyfikowania dotychczasowych stron. Dzięki temu możesz skonfigurować „element 2CH” dla zalogowanych użytkowników, który może przechwytywać wszystkie żądania sieci wysyłane przez Twoją stronę i wymieniać tokeny tak samo jak aplikacje mobilne.
W większości przypadków serwer ma już punkt końcowy używany przez aplikacje mobilne do uzyskiwania nowych krótkotrwałych tokenów, zwykle za pomocą protokołu OAuth. Aby włączyć powyższy wzór w internecie, ten punkt końcowy musi zostać zaktualizowany, aby wiedzieć, kiedy jest wywoływany przez skrypt service worker, a następnie zwrócić nowy krótkotrwały plik cookie sesji sformatowany w sposób, którego oczekują już inne strony w witrynie.
Jeśli na serwerze nie ma takiego punktu końcowego, może on utworzyć go tylko do zarządzania sesją przeglądarki.
Wzór z 2 tokenami z użyciem usług działających w tle jest dość podobny do OAuth 2.0. Jeśli masz już punkt końcowy tokena OAuth, możesz go prawdopodobnie ponownie użyć z usługami działającymi w tle do uwierzytelniania w internecie.
Możesz się też zastanawiać, co się stanie, jeśli użytkownik otworzy przeglądarkę, która nie obsługuje usług działających w tle. Jeśli zastosujesz powyższe podejście, użytkownicy nie odczują różnicy i nadal będą korzystać z krótkich sesji.
Opublikowaliśmy przykładowy klienta i oprogramowanie backendowe. Mamy nadzieję, że sprawdzisz to samodzielnie i wypełnisz ankietę na temat zarządzania sesjami.