Jak obsługiwać blokowanie plików cookie innych firm w przeglądarkach

Wiele przeglądarek blokuje pliki cookie innych firm, pliki cookie dotyczące żądań do domen innych niż domena wyświetlana na pasku adresu przeglądarki. Te pliki cookie są również nazywane plikami cookie między domenami. Ten blok przerywa niejawny przepływ i wymaga nowych wzorców uwierzytelniania w celu pomyślnego zalogowania użytkowników. W Platforma tożsamości Microsoft używamy przepływu kodu autoryzacji z kluczem dowodowym dla programu Code Exchange (PKCE) i tokenami odświeżania, aby użytkownicy logowali się, gdy pliki cookie innych firm są blokowane. Ten przepływ kodu autoryzacji z kluczem dowodowym dla podejścia do wymiany kodu jest zalecany w przepływie niejawnym.

Co to jest funkcja Intelligent Tracking Protection (ITP) i piaskownica prywatności?

Przeglądarka Apple Safari ma domyślnie włączoną funkcję ochrony prywatności o nazwie Intelligent Tracking Protection lub ITP. Przeglądarka Chrome ma inicjatywę prywatności przeglądarki o nazwie Piaskownica prywatności. Te inicjatywy obejmują wiele różnych działań związanych z prywatnością przeglądarki przez przeglądarki i mają różne osie czasu. Oba wysiłki blokują pliki cookie "innych firm" na żądaniach obejmujących domeny, z przeglądarkami Safari i Brave domyślnie blokują pliki cookie innych firm. Chrome ogłosił niedawno, że domyślnie zaczną blokować pliki cookie innych firm. Piaskownica prywatności zawiera zmiany w magazynie podzielonym na partycje, a także blokowanie plików cookie innych firm.

Typową formą śledzenia użytkowników jest ładowanie elementu iframe do witryny innej firmy w tle i używanie plików cookie w celu skorelowania użytkownika przez Internet. Niestety ten wzorzec jest również standardowym sposobem implementowania niejawnego przepływu w aplikacjach jednostronicowych (SPA). Przeglądarka, która blokuje pliki cookie innych firm w celu ochrony prywatności użytkowników, może również zablokować funkcjonalność SPA. Korzystanie z niejawnego przepływu w usługach SPA nie jest już zalecane z powodu blokowania plików cookie innych firm i związanych z nim zagrożeń bezpieczeństwa.

Rozwiązanie opisane w tym artykule działa we wszystkich tych przeglądarkach lub w dowolnym miejscu plików cookie innych firm jest blokowane.

Omówienie rozwiązania

Aby kontynuować uwierzytelnianie użytkowników w usługach SPA, deweloperzy aplikacji muszą używać przepływu kodu autoryzacji. W przepływie kodu uwierzytelniania dostawca tożsamości wystawia kod, a SPA wykonuje kod tokenu dostępu i token odświeżania. Gdy aplikacja wymaga nowych tokenów, może użyć przepływu tokenu odświeżania, aby uzyskać nowe tokeny. Biblioteka Microsoft Authentication Library (MSAL) dla języka JavaScript w wersji 2.0 lub nowszej implementuje przepływ kodu autoryzacji dla umów SPA i, z drobnymi aktualizacjami, jest elementem zastępującym MSAL.js 1.x. Zobacz przewodnik migracji dotyczący przenoszenia spa z niejawnego do przepływu kodu uwierzytelniania.

W przypadku Platforma tożsamości Microsoft usługi SPA i klientów natywnych są zgodne z podobnymi wskazówkami dotyczącymi protokołu:

• Korzystanie z wyzwania kodu PKCE
  • Klucz PKCE jest wymagany dla spAs w Platforma tożsamości Microsoft. PKCE jest zalecana dla klientów natywnych i poufnych.
• Brak użycia wpisu tajnego klienta

Dostawcy usług mają jeszcze dwa ograniczenia:

• Identyfikator URI przekierowania musi być oznaczony jako typ spa , aby włączyć mechanizm CORS w punktach końcowych logowania.
• Tokeny odświeżania wystawione za pośrednictwem przepływu kodu autoryzacji w celu spa przekierowania identyfikatorów URI mają okres istnienia 24-godzinny, a nie 90-dniowy okres istnienia.

Implikacje dotyczące wydajności i środowiska użytkownika

Niektóre aplikacje korzystające z niejawnego przepływu próbują zalogować się bez przekierowywania, otwierając element iframe logowania przy użyciu polecenia prompt=none. W większości przeglądarek to żądanie odpowiada za pomocą tokenów dla aktualnie zalogowanego użytkownika (przy założeniu, że udzielono zgody). Ten wzorzec oznacza, że aplikacje nie wymagały pełnego przekierowania strony w celu zalogowania użytkownika, poprawy wydajności i środowiska użytkownika — użytkownik odwiedza stronę internetową i jest już zalogowany. Ponieważ prompt=none element iframe nie jest już opcją, gdy pliki cookie innych firm są blokowane, aplikacje muszą dostosować wzorce logowania, aby mieć wystawiony kod autoryzacji.

Bez plików cookie innych firm istnieją dwa sposoby wykonywania logowania:

• Przekierowania pełnej strony
  • Po pierwszym załadowaniu SPA przekieruj użytkownika do strony logowania, jeśli żadna sesja już nie istnieje (lub jeśli sesja wygasła). Przeglądarka użytkownika odwiedza stronę logowania, prezentuje pliki cookie zawierające sesję użytkownika, a następnie jest przekierowywana z powrotem do aplikacji przy użyciu kodu i tokenów w fragmentcie.
  • Przekierowanie powoduje dwukrotne załadowanie SPA. Postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi buforowania umów SPA, aby aplikacja nie została dwukrotnie pobrana.
  • Rozważ posiadanie sekwencji przed załadowaniem w aplikacji, która sprawdza sesję logowania i przekierowuje do strony logowania przed pełnym rozpakowywaniem aplikacji i wykonywaniem ładunku JavaScript.
• Wyskakujące okienka
  • Jeśli środowisko użytkownika (UX) przekierowania pełnej strony nie działa dla aplikacji, rozważ użycie wyskakującego okienka do obsługi uwierzytelniania.
  • Gdy okienko podręczne zakończy przekierowywanie do aplikacji po uwierzytelnieniu, kod w procedurze obsługi przekierowania będzie przechowywać kod uwierzytelniania i tokeny w magazynie lokalnym do użycia przez aplikację. MSAL.js obsługuje wyskakujące okienka na potrzeby uwierzytelniania, podobnie jak większość bibliotek.
  • Przeglądarki zmniejszają obsługę wyskakujących okienek, więc mogą nie być najbardziej niezawodną opcją. Interakcja użytkownika ze SPA przed utworzeniem wyskakującego okienka może być konieczna do spełnienia wymagań przeglądarki.

Firma Apple opisuje metodę wyskakujących okienek jako tymczasową poprawkę zgodności, aby zapewnić oryginalny dostęp do plików cookie innych firm. Chociaż firma Apple może usunąć ten transfer uprawnień w przyszłości, nie wpłynie to na wskazówki tutaj.

W tym miejscu okienko podręczne jest używane jako nawigacja po pierwszej stronie do strony logowania, aby można było znaleźć sesję i można podać kod uwierzytelniania. Powinno to kontynuować pracę w przyszłości.

Deweloperzy mogą nadal używać prompt=none z oczekiwaniami, że widzą wyższy współczynnik błędów interacion_required , gdy pliki cookie innych firm są blokowane. Zaleca się, aby zawsze mieć rezerwową metodę interaktywną, jeśli wystąpią błędy podczas pozyskiwania tokenu dyskretnego.

Korzystanie z elementów iframe

Typowym wzorcem w aplikacjach internetowych jest użycie elementu iframe do osadzania jednej aplikacji wewnątrz innej: ramka najwyższego poziomu obsługuje uwierzytelnianie użytkownika i aplikację hostowaną w elemencie iframe może ufać, że użytkownik jest zalogowany, pobierając tokeny dyskretnie przy użyciu przepływu niejawnego. Jednak istnieje kilka zastrzeżeń do tego założenia niezależnie od tego, czy pliki cookie innych firm są włączone, czy zablokowane w przeglądarce.

Pozyskiwanie tokenu dyskretnego nie działa już, gdy pliki cookie innych firm są blokowane — aplikacja osadzona w elemecie iframe musi przełączyć się na używanie wyskakujących okienek w celu uzyskania dostępu do sesji użytkownika, ponieważ nie może przejść do strony logowania w osadzonej ramce.

Możesz osiągnąć logowanie jednokrotne między aplikacjami iframed i nadrzędnymi z dostępem do interfejsu API skryptów JavaScript z tego samego źródła i między źródłami, przekazując wskazówkę użytkownika (konta) z aplikacji nadrzędnej do aplikacji iframed. Aby uzyskać więcej informacji, zobacz Using MSAL.js in iframed apps in the iframed apps in the MSAL.js repository on GitHub (Używanie MSAL.js w aplikacjach iframed w repozytorium MSAL.js w witrynie GitHub).

Wpływ na zabezpieczenia tokenów odświeżania w przeglądarce

Ataki skryptów między witrynami (XSS) lub naruszone pakiety JS mogą ukraść token odświeżania i używać go zdalnie, dopóki nie wygaśnie lub zostanie odwołany. Deweloperzy aplikacji są odpowiedzialni za zmniejszenie ryzyka związanego z tworzeniem skryptów między witrynami. Aby zminimalizować ryzyko kradzieży tokenów odświeżania, umowy SPA są wystawiane tokeny ważne tylko przez 24 godziny. Po upływie 24 godzin aplikacja musi uzyskać nowy kod autoryzacji za pośrednictwem strony logowania ramki najwyższego poziomu.

Ten wzorzec tokenu odświeżania ograniczonego okresu istnienia został wybrany jako równowaga między zabezpieczeniami a obniżonym środowiskiem użytkownika. Bez tokenów odświeżania lub plików cookie innych firm przepływ kodu autoryzacji (zalecany przez wersję roboczą najlepszych rozwiązań dotyczących zabezpieczeń protokołu OAuth) staje się uciążliwy, gdy wymagane są nowe lub dodatkowe tokeny. Dla każdego tokenu jest wymagany pełny przekierowanie lub wyskakujące okienko, za każdym razem, gdy token wygaśnie (zazwyczaj co godzinę dla tokenów Platforma tożsamości Microsoft).

Środki zaradcze dotyczące typu użytkownika

Nie wszyscy użytkownicy i aplikacje mają jednolity wpływ na pliki cookie innych firm. Istnieją pewne scenariusze, w których ze względu na architekturę lub zarządzanie urządzeniami można wykonywać dyskretne wywołania odnawiania tokenów bez plików cookie innych firm.

W przypadku scenariuszy zarządzanych urządzeń w przedsiębiorstwie niektóre kombinacje przeglądarki i platformy obsługują dostęp warunkowy urządzenia. Stosowanie tożsamości urządzenia minimalizuje potrzebę plików cookie innych firm, ponieważ stan uwierzytelniania może pochodzić z urządzenia zamiast przeglądarki.

W przypadku scenariuszy aplikacji usługi Azure AD B2C klienci mogą skonfigurować niestandardową domenę logowania w celu dopasowania do domeny aplikacji. Przeglądarki nie blokują plików cookie innych firm w tym scenariuszu, ponieważ pliki cookie pozostają w tej samej domenie (na przykład login.contoso.com do app.contoso.com).

Ograniczenia dotyczące wylogowywanie kanału frontonu bez plików cookie innych firm

Podczas podpisywania użytkownika z SPA, MSAL.js zaleca użycie metody wylogowania wyskakującego lub przekierowania. Chociaż spowoduje to wyczyszczenie sesji uwierzytelniania na serwerze i w magazynie przeglądarki, istnieje ryzyko, że bez dostępu do plików cookie innych firm nie wszystkie aplikacje federacyjne będą widzieć wylogowywanie w tym samym czasie. Jest to znane ograniczenie specyfikacji logout 1.0 openID front-channel. Oznacza to, że istniejące tokeny dostępu dla innych aplikacji dla tego samego użytkownika będą nadal ważne do czasu wygaśnięcia. Użytkownik może wylogować się z aplikacji A na karcie A, ale aplikacja B na karcie B nadal będzie wyświetlana jako zalogowana w celu uzyskania prawidłowego czasu tokenu dostępu. Gdy token aplikacji B wygaśnie i zostanie wykonane wywołanie do serwera w celu uzyskania nowego tokenu, aplikacja B otrzymuje odpowiedź z serwera, że sesja wygasła i monituje użytkownika o uwierzytelnienie.

Strona wylogowywania firmy Microsoft i najlepsze rozwiązania dotyczące prywatności w Internecie zaleca, aby użytkownicy zamykali wszystkie okna przeglądarki po wylogowaniu się z aplikacji.

Następne kroki

Aby uzyskać więcej informacji na temat przepływu kodu autoryzacji i MSAL.js, zobacz:

• Przepływ kodu autoryzacji.
• MSAL.js 2.0 — szybki start.