Zpracování blokování souborů cookie třetích stran v prohlížečích

  • Článek

Mnoho prohlížečů blokuje soubory cookie třetích stran, soubory cookie na žádosti o jiné domény, než je doména zobrazená na adresní řádku prohlížeče. Tyto soubory cookie se také označují jako soubory cookie napříč doménou. Tento blok přeruší implicitní tok a k úspěšnému přihlášení uživatelů vyžaduje nové vzory ověřování. Na platformě Microsoft Identity Platform používáme tok autorizace s ověřovacím klíčem pro exchange kódu (PKCE) a obnovovacími tokeny pro zachování přihlašování uživatelů při blokování souborů cookie třetích stran.

Co je inteligentní ochrana před sledováním (ITP) a sandbox ochrany osobních údajů?

Apple Safari má výchozí funkci ochrany osobních údajů s názvem Inteligentní ochrana před sledováním nebo ITP. Chrome má iniciativu ochrany osobních údajů prohlížeče s názvem Sandbox Pro ochranu osobních údajů. Tyto iniciativy zahrnují mnoho různých úsilí o ochranu osobních údajů v prohlížečích a mají různé časové osy. Obě snahy blokují soubory cookie třetích stran u žádostí, které používají různé domény, ve výchozím nastavení blokují soubory cookie třetích stran Safari a Brave. Chrome nedávno oznámil, že ve výchozím nastavení začnou blokovat soubory cookie třetích stran. Sandbox ochrany osobních údajů zahrnuje změny rozděleného úložiště a blokování souborů cookie třetích stran.

Běžnou formou sledování uživatelů se provádí načtením prvku iframe na web třetí strany na pozadí a použitím souborů cookie ke korelaci uživatele přes internet. Tento model je bohužel také standardním způsobem implementace implicitního toku v jednostrákových aplikacích (SPA). Prohlížeč, který blokuje soubory cookie třetích stran za účelem ochrany osobních údajů uživatele, může také blokovat funkce spa.

Řešení popsané v tomto článku funguje ve všech těchto prohlížečích nebo kdekoli, kde jsou soubory cookie třetích stran blokované.

Přehled řešení

Aby vývojáři aplikací mohli dál ověřovat uživatele v spA, musí používat tok autorizačního kódu. V toku ověřovacího kódu vydá zprostředkovatel identity kód a SPA uplatní kód pro přístupový token a obnovovací token. Když aplikace vyžaduje nové tokeny, může k získání nových tokenů použít tok obnovovacího tokenu. Knihovna MICROSOFT Authentication Library (MSAL) pro JavaScript verze 2.0 a vyšší implementuje tok autorizačního kódu pro spa a s dílčími aktualizacemi je náhradou za MSAL.js 1.x. Informace o přesunu spa z implicitního toku kódu na ověřovací kód najdete v průvodci migrací.

Pro platformu Microsoft Identity Platform se služby SPA a nativní klienti řídí podobnými pokyny k protokolu:

  • Použití výzvy kódu PKCE
    • Infrastruktura veřejných klíčů (PKCE) se vyžaduje pro služby SPA na platformě Microsoft Identity Platform. Infrastruktura veřejných klíčů se doporučuje pro nativní a důvěrné klienty.
  • Bez použití tajného klíče klienta

SpA mají dvě další omezení:

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

Vliv na výkon a uživatelské prostředí

Některé aplikace používající implicitní pokus o tok přihlášení bez přesměrování otevřením prvku iframe přihlášení pomocí prompt=none. Ve většině prohlížečů tento požadavek reaguje tokeny pro aktuálně přihlášeného uživatele (za předpokladu, že je udělen souhlas). Tento vzor znamenal, že aplikace nepotřebují přesměrovávání celé stránky, aby se uživatel přihlásil, zlepšil výkon a uživatelské prostředí – uživatel navštíví webovou stránku a už je přihlášený. Vzhledem k tomu prompt=none , že v prvku iframe už není možnost, když jsou soubory cookie třetích stran blokované, musí aplikace upravit vzory přihlašování tak, aby měly vystavený autorizační kód.

Bez souborů cookie třetích stran existují dva způsoby, jak se přihlásit:

  • Přesměrování celé stránky
    • Při prvním načtení spa přesměrujte uživatele na přihlašovací stránku, pokud ještě neexistuje žádná relace (nebo pokud vypršela platnost relace). Prohlížeč uživatele navštíví přihlašovací stránku, zobrazí soubory cookie obsahující relaci uživatele a pak se přesměruje zpět do aplikace s kódem a tokeny v fragmentu.
    • Přesměrování způsobí, že spa se načte dvakrát. Dodržujte osvědčené postupy pro ukládání spA do mezipaměti, aby se aplikace nestáhnula dvakrát.
    • Zvažte, jestli se v aplikaci nespustí před načtením sekvence, která kontroluje relaci přihlášení a přesměruje ji na přihlašovací stránku, než se aplikace úplně rozbalí a spustí datovou část JavaScriptu.
  • Dav
    • Pokud uživatelské prostředí (UX) přesměrování celé stránky pro aplikaci nefunguje, zvažte použití automaticky otevíraných oken ke zpracování ověřování.
    • Když se automaticky otevírané okno dokončí přesměrování do aplikace po ověření, kód v obslužné rutině přesměrování uloží ověřovací kód a tokeny v místním úložišti, které bude aplikace používat. MSAL.js podporuje automaticky otevírané okno pro ověřování, stejně jako většina knihoven.
    • Prohlížeče snižují podporu automaticky otevíranějších oken, takže nemusí být nejspolehlivější možností. Uživatelská interakce s SPA před vytvořením automaticky otevírané aplikace může být nutná k splnění požadavků prohlížeče.

Apple popisuje místní metodu jako dočasnou opravu kompatibility, která poskytuje původnímu oknu přístup k souborům cookie třetích stran. I když apple může tento přenos oprávnění v budoucnu odebrat, nebude to mít vliv na pokyny zde.

V této části se automaticky otevírané okno používá jako navigace první strany na přihlašovací stránku, aby se našla relace a bylo možné zadat ověřovací kód. To by mělo pokračovat v budoucnosti.

Vývojáři můžou dál používat prompt=none s očekáváním, že se jim při zablokování souborů cookie třetích stran zobrazí vyšší míra chyb interacion_required . Doporučení je vždy mít interaktivní náhradní metodu, pokud dojde k selhání během získání tichého tokenu.

Použití elementů iframe

Běžným vzorem ve webových aplikacích je použití prvku iframe k vložení jedné aplikace do jiné: rámec nejvyšší úrovně zpracovává ověřování uživatele a aplikace hostovaná v prvku iframe může důvěřovat tomu, že je uživatel přihlášený, a bezobslužně načítá tokeny pomocí implicitního toku. Existuje však několik upozornění na tento předpoklad bez ohledu na to, jestli jsou soubory cookie třetích stran povolené nebo blokované v prohlížeči.

Získání tichého tokenu už nefunguje, když jsou blokované soubory cookie třetích stran – aplikace vložená do prvku iframe musí přepnout na používání automaticky otevíraných oken pro přístup k relaci uživatele, protože nemůže přejít na přihlašovací stránku v rámci vloženého rámce.

Můžete dosáhnout jednotného přihlašování mezi aplikacemi iframed a nadřazenými aplikacemi se stejným původem a přístupem k rozhraní JAVAScript API pro různé zdroje předáním nápovědy uživatele (účtu) z nadřazené aplikace do aplikace iframed. Další informace najdete v tématu Použití MSAL.js v aplikacích iframe v úložišti MSAL.js na GitHubu.

Vliv na zabezpečení obnovovacích tokenů v prohlížeči

Skriptování mezi weby (XSS) útoky nebo ohrožené balíčky JS mohou ukrást obnovovací token a používat ho vzdáleně, dokud nevyprší platnost nebo se neodvolá. Vývojáři aplikací zodpovídají za snížení rizika jejich aplikace na skriptování mezi weby. Aby se minimalizovalo riziko odcizených obnovovacích tokenů, jsou tokeny spA vystaveny pouze po dobu 24 hodin. Po 24 hodinách musí aplikace získat nový autorizační kód prostřednictvím rámce nejvyšší úrovně na přihlašovací stránce.

Tento model obnovovacího tokenu s omezenou životností byl zvolen jako rovnováhu mezi zabezpečením a sníženým využitím uživatelského rozhraní. Bez obnovovacích tokenů nebo souborů cookie třetích stran se tok autorizačního kódu (podle doporučení konceptu osvědčených postupů zabezpečení OAuth) stává v případě, že jsou vyžadovány nové nebo další tokeny. Pro každý token je potřeba přesměrování celé stránky nebo automaticky otevírané okno pokaždé, když vyprší platnost tokenu (obvykle za hodinu pro tokeny Microsoft Identity Platform).

Omezení rizik specifických pro konkrétní typ uživatele

Ne všichni uživatelé a aplikace jsou jednotně ovlivněni soubory cookie třetích stran. Existují některé scénáře, kdy se kvůli architektuře nebo správě zařízení dají bezobslužná volání obnovit tokeny bez souborů cookie třetích stran.

Pro scénáře spravovaných podnikových zařízení mají určité kombinace prohlížečů a platforem podporu podmíněného přístupu zařízení. Použití identity zařízení minimalizuje potřebu souborů cookie třetích stran, protože stav ověřování může pocházet ze zařízení místo prohlížeče.

Pro scénáře aplikací Azure AD B2C mohou zákazníci nastavit vlastní přihlašovací doménu tak, aby odpovídala doméně aplikace. Prohlížeče by v tomto scénáři neblokovaly soubory cookie třetích stran, protože soubory cookie zůstávají ve stejné doméně (např. login.contoso.com k app.contoso.com).

Omezení odhlášení front-channel bez souborů cookie třetích stran

Při odhlášení uživatele z spa MSAL.js doporučujeme použít metodu odhlášení automaticky otevíraných oken nebo přesměrování. I když se tím vymaže ověřovací relace na serveru a v úložišti prohlížeče, existuje riziko, že bez přístupu k souborům cookie třetích stran se současně nezobrazí žádné federované aplikace. Jedná se o známé omezení specifikace Odhlášení z openID front-channel 1.0. To znamená, že stávající přístupové tokeny pro jiné aplikace pro stejného uživatele budou nadále platné až do doby vypršení platnosti. Uživatel se může odhlásit z aplikace A na kartě A, ale aplikace B na kartě B se stále zobrazí jako přihlášená pro zbývající platný čas přístupového tokenu. Když vyprší platnost tokenu aplikace B a provede se volání na server, aby získal nový token, aplikace B obdrží odpověď ze serveru, jehož platnost vypršela, a vyzve uživatele k ověření.

Osvědčené postupy microsoftu pro odhlášení a ochranu osobních údajů v internetu doporučují, aby uživatelé po odhlášení z aplikace zavřeli všechna okna prohlížeče.

Další kroky

Další informace o toku autorizačního kódu a MSAL.js najdete tady: