Wszyscy lubimy, że aplikacje natywne wymagają logowania tylko raz i zapamiętują użytkownika, dopóki nie powiesz, że chcesz się wylogować. Niestety sieć nie zawsze tak działa.
Teraz, gdy urządzenia, zwłaszcza urządzenia mobilne, mają bardziej osobisty charakter, a większa liczba stron wysyła cały ruch przez HTTPS, co zmniejsza ryzyko kradzieży tokenów, witryny powinny ponownie rozważyć zasady dotyczące krótkotrwałych plików cookie i zastosować bardziej przyjazne dla użytkownika, dłuższe sesje.
Nawet jeśli chcesz wydłużyć sesję, niektóre witryny nie weryfikują uwierzytelniania użytkownika przy każdym żądaniu (inaczej mówiąc, nie można unieważnić po wywołaniu pliku cookie sesji). Sesje są zwykle krótkie, a użytkownik musi często logować się na swoje konto, co pozwala na ponowną weryfikację jego uwierzytelniania. Na przykład zmiana hasła może doprowadzić do unieważnienia istniejących sesji w znanym czasie.
Jeśli korzystasz z tej metody, udostępniamy rozwiązanie techniczne, które może pomóc Ci automatycznie zweryfikować bezstanowy plik cookie uwierzytelniania. Działanie tej funkcji opiera się na zastosowaniu dodatkowego, długoterminowego tokena, który może służyć do odświeżania istniejącego krótkotrwałego pliku cookie uwierzytelniania. Wykorzystanie nowego wzorca skryptu service worker pozwala nam regularnie „logować się” z wykorzystaniem długoterminowego tokena, weryfikować uwierzytelnianie użytkownika (na przykład sprawdzać, czy ostatnio nie zmieniał hasła lub w inny sposób unieważnił sesji) i ponownie wysyłać nowy, krótkotrwały plik cookie uwierzytelniania.
Praktyczna propozycja przejścia na bezpieczne długie sesje w internecie
W tym poście opisujemy nową technikę o nazwie 2-Cookie-Handoff (2CH). W tym artykule chcemy poznać opinie społeczności na temat tego, czy takie podejście wydaje się pozytywne, a jeśli tak, będziemy współpracować z przedstawicielami branży nad udokumentowaniem sprawdzonych metod używania 2CH.
Mechanizmy Service Worker to nowa technologia obsługiwana przez wiele przeglądarek, takich jak Chrome, Firefox i Opera. Wkrótce pojawi się też w Edge. Umożliwiają przechwytywanie wszystkich żądań sieciowych pochodzących z witryny za pomocą wspólnego punktu kodu klienta bez konieczności modyfikowania istniejących stron. Umożliwia to skonfigurowanie dla zalogowanych użytkowników instancji roboczej 2CH, która może przechwytywać wszystkie żądania sieciowe wysyłane przez stronę i wykonywać zamianę tokenów tak samo jak aplikacje mobilne.
W większości przypadków, gdy serwer ma już punkt końcowy, z którego aplikacje mobilne korzystają, do uzyskania nowego tokena o krótkim czasie ważności, zwykle z użyciem protokołu OAuth. Aby umożliwić działanie powyższego wzorca w internecie, trzeba zaktualizować ten punkt końcowy, aby rozpoznawał, kiedy jest wywoływany przez skrypt service worker. Następnie musi zwrócić nowy, krótkotrwały plik cookie sesji sformatowany w sposób, jakiego oczekują inne strony w witrynie.
Jeśli Twój serwer nie ma jeszcze takiego punktu końcowego, może go utworzyć tylko na potrzeby zarządzania sesjami przeglądarki.
Wzorzec 2 tokenów z mechanizmami Service Worker jest dość ściśle zgodny ze wzorcem OAuth 2.0. Jeśli korzystasz już z punktu końcowego tokena OAuth, prawdopodobnie możesz go ponownie użyć z skryptami service worker do uwierzytelniania internetowego.
Być może zastanawiasz się, co się stanie, gdy użytkownik otworzy przeglądarkę, która nie obsługuje mechanizmów Service Worker. Jeśli wdrożysz powyższe podejście, nie zaobserwujesz żadnej różnicy, a sesje będą krótkie.
Opublikowaliśmy przykładowego klienta i backendu. Mamy nadzieję, że sami wypróbujesz tę funkcję i weźmiesz udział w ankiecie na temat zarządzania sesjami.