Külső cookie-k blokkolásának kezelése böngészőkben

Számos böngésző letiltja a harmadik féltől származó cookie-kat, a cookie-kat a böngésző címsorában látható tartománytól eltérő tartományokra irányuló kérelmek esetén. Ezeket a cookie-kat tartományközi cookie-knak is nevezik. Ez a blokk megszakítja az implicit folyamatot, és új hitelesítési mintákat igényel a felhasználók sikeres bejelentkezéséhez. A Microsoft Identitásplatform az engedélyezési folyamatot a Code Exchange ellenőrzőkulcsával (PKCE) és frissítési jogkivonatokkal használjuk, hogy a felhasználók bejelentkezve maradjanak, amikor a külső cookie-k le vannak tiltva.

Mi az az Intelligent Tracking Protection (ITP) és az adatvédelmi tesztkörnyezet?

Az Apple Safari rendelkezik egy alapértelmezett adatvédelmi funkcióval, az Intelligent Tracking Protection vagy az ITP néven. A Chrome rendelkezik egy Adatvédelmi tesztkörnyezet nevű böngésző adatvédelmi kezdeményezéssel. Ezek a kezdeményezések a böngészők különböző adatvédelmi erőfeszítéseit foglalják magukban, és különböző ütemtervekkel rendelkeznek. Mindkét törekvés letiltja a "harmadik féltől származó" cookie-kat a tartományok közötti kérelmek esetén, a Safari és a Brave alapértelmezés szerint letiltja a harmadik féltől származó cookie-kat. A Chrome nemrég bejelentette, hogy alapértelmezés szerint elkezdik blokkolni a harmadik féltől származó cookie-kat. Az adatvédelmi tesztkörnyezet tartalmazza a particionált tároló módosításait és a külső cookie-k blokkolását.

A felhasználók nyomon követésének gyakori formája, ha egy iframe-et tölt be a háttérben egy külső webhelyre, és cookie-kat használva korrelálja a felhasználót az interneten keresztül. Sajnos ez a minta az implicit folyamat egyoldalas alkalmazásokban (SLA-kban) való implementálásának szabványos módja is. A böngésző, amely letiltja a harmadik féltől származó cookie-kat a felhasználói adatvédelem érdekében, letilthatja a SPA funkcióit is.

A cikkben ismertetett megoldás az összes böngészőben működik, vagy bárhol, ahol a külső cookie-k le vannak tiltva.

A megoldás áttekintése

A felhasználók hitelesítésének folytatásához az alkalmazásfejlesztőknek az engedélyezési kódfolyamatot kell használniuk. A hitelesítési kód folyamatában az identitásszolgáltató kiad egy kódot, az SPA pedig beváltja a kódot egy hozzáférési jogkivonathoz és egy frissítési jogkivonathoz. Ha az alkalmazás új jogkivonatokat igényel, a frissítési jogkivonat-folyamattal új jogkivonatokat szerezhet be. A JavaScript 2.0-s vagy újabb verziójához készült Microsoft Authentication Library (MSAL) implementálja az engedélyezési kódfolyamatot az SLA-khoz, és kisebb frissítésekkel az 1.x MSAL.js egy legördülő menü. Tekintse meg a spa implicit kódfolyamatról a hitelesítési kódfolyamra való áthelyezésének migrálási útmutatóját .

A Microsoft Identitásplatform esetében az SLA-k és a natív ügyfelek hasonló protokoll-útmutatást követnek:

• PKCE-kódfeladat használata
  • A PKCE szükséges a Microsoft Identitásplatform lévő SLA-khoz. A PKCE natív és bizalmas ügyfelek számára ajánlott .
• Az ügyfél titkos kódjának használata nélkül

Az SLA-knak két további korlátozásuk van:

• Az átirányítási URI-t típusként spa kell megjelölni a CORS bejelentkezési végpontokon való engedélyezéséhez.
• Az átirányítási URI-khoz spa az engedélyezési kód folyamatán keresztül kibocsátott jogkivonatok 90 napos élettartam helyett 24 órás élettartamot igényelnek.

A teljesítmény és az UX következményei

Egyes alkalmazások, amelyek az implicit folyamattal próbálnak bejelentkezni átirányítás nélkül, megnyitnak egy bejelentkezési iframe-et a használatával prompt=none. A legtöbb böngészőben ez a kérés a jelenleg bejelentkezett felhasználó jogkivonataival válaszol (feltételezve, hogy a hozzájárulás meg van adva). Ez a minta azt jelentette, hogy az alkalmazásoknak nem kellett egy teljes oldal átirányítása a felhasználó bejelentkezéséhez, javítva a teljesítményt és a felhasználói élményt – a felhasználó felkeresi a weblapot, és már bejelentkezett. Mivel prompt=none az iframe-ben már nincs lehetőség harmadik féltől származó cookie-k letiltására, az alkalmazásoknak módosítaniuk kell a bejelentkezési mintáikat, hogy egy engedélyezési kódot adjanak ki.

Külső cookie-k nélkül kétféleképpen lehet bejelentkezni:

• Teljes oldal átirányítása
  • Az SPA első betöltésekor átirányítsa a felhasználót a bejelentkezési lapra, ha még nincs munkamenet (vagy ha a munkamenet lejárt). A felhasználó böngészője felkeresi a bejelentkezési oldalt, megjeleníti a felhasználói munkamenetet tartalmazó cookie-kat, majd visszairányítja az alkalmazáshoz a kóddal és a töredékben lévő jogkivonatokkal.
  • Az átirányítás azt eredményezi, hogy az SPA kétszer töltődik be. Kövesse az ajánlott eljárásokat az SLA-k gyorsítótárazására, hogy az alkalmazás ne legyen kétszer teljes mértékben letöltve.
  • Fontolja meg egy előzetes betöltési sorozatot az alkalmazásban, amely ellenőrzi a bejelentkezési munkamenetet, és átirányítja a bejelentkezési oldalra, mielőtt az alkalmazás teljes mértékben kicsomagolja és végrehajtja a JavaScript hasznos adatait.
• Lakosság
  • Ha egy teljes oldal átirányításának felhasználói felülete (UX) nem működik az alkalmazás számára, fontolja meg egy előugró ablak használatát a hitelesítés kezeléséhez.
  • Amikor az előugró ablak befejezi az alkalmazásra való átirányítást a hitelesítés után, az átirányítási kezelőben lévő kód tárolja a hitelesítési kódot, a jogkivonatokat pedig a helyi tárolóban, amelyet az alkalmazás használni fog. MSAL.js támogatja az előugró ablakokat a hitelesítéshez, a legtöbb kódtárhoz hasonlóan.
  • A böngészők csökkentik az előugró ablakok támogatását, ezért előfordulhat, hogy nem ezek a legmegbízhatóbbak. Előfordulhat, hogy az előugró ablak létrehozása előtt felhasználói interakcióra van szükség az SPA-val a böngésző követelményeinek teljesítéséhez.

Az Apple egy előugró módszert ír le ideiglenes kompatibilitási javításként, amely hozzáférést biztosít az eredeti ablaknak a külső cookie-khoz. Bár az Apple a jövőben eltávolíthatja az engedélyek átvitelét, az itt ismertetett útmutatásra nem lesz hatással.

Itt az előugró ablak lesz használva a bejelentkezési lap első féltől származó navigációjaként, hogy egy munkamenetet találjon, és meg lehessen adni egy hitelesítési kódot. Ennek a jövőben is működnie kell.

A fejlesztők továbbra is használhatják prompt=none azt a várakozást, hogy a harmadik féltől származó cookie-k letiltásakor magasabb interacion_required-hibákat tapasztalnak. A javaslat az, hogy mindig legyen egy interaktív módszer tartaléka, ha a csendes jogkivonatok beszerzése során hibák lépnek fel.

Iframe-ek használata

A webalkalmazások gyakori mintája, hogy egy iframe használatával ágyazza be az egyik alkalmazást egy másikba: a legfelső szintű keret kezeli a felhasználó hitelesítését, és az iframe-ben üzemeltetett alkalmazás megbízhat abban, hogy a felhasználó bejelentkezett, és az implicit folyamat használatával csendesen beolvassa a jogkivonatokat. Ennek a feltételezésnek azonban van néhány kikötése, függetlenül attól, hogy a böngészőben engedélyezve vagy letiltva vannak-e a harmadik féltől származó cookie-k.

A csendes jogkivonat-beszerzés már nem működik, ha a külső cookie-k le vannak tiltva – az iframe-be ágyazott alkalmazásnak felugró ablakokra kell váltania a felhasználó munkamenetének eléréséhez, mivel beágyazott kereten belül nem tud navigálni a bejelentkezési lapra.

Az azonos eredetű és több forrású JavaScript-szkript API-hozzáféréssel rendelkező iframed és szülőalkalmazások közötti egyszeri bejelentkezést úgy érheti el, ha a szülőalkalmazásból egy felhasználói (fiók-) tippet ad át az iframed alkalmazásnak. További információ: MSAL.js használata iframed-alkalmazásokban a GitHub MSAL.js-adattárában.

A frissítési jogkivonatok biztonsági következményei a böngészőben

A helyek közötti szkriptelés (XSS) támadásai vagy a feltört JS-csomagok ellophatják a frissítési jogkivonatot, és távolról használhatják, amíg lejár vagy vissza nem vonják. Az alkalmazásfejlesztők felelősek azért, hogy csökkentsék az alkalmazás helyközi szkriptelésre vonatkozó kockázatát. Az ellopott frissítési jogkivonatok kockázatának minimalizálása érdekében az SLA-k csak 24 órán keresztül érvényes jogkivonatokat bocsátanak ki. 24 óra elteltével az alkalmazásnak be kell szereznie egy új engedélyezési kódot a bejelentkezési oldal felső szintű keretes látogatásán keresztül.

Ez a korlátozott élettartamú frissítési jogkivonat-minta lett kiválasztva a biztonság és a csökkentett UX közötti egyensúlyként. Frissítési jogkivonatok vagy harmadik féltől származó cookie-k nélkül az engedélyezési kód folyamata (az OAuth biztonsági ajánlott eljárásainak tervezete szerint) eggyel újabb vagy újabb jogkivonatok megkövetelése esetén válik szükségessé. Minden egyes jogkivonathoz teljes oldalátirányításra vagy előugró ablakra van szükség, minden alkalommal, amikor egy jogkivonat lejár (általában óránként, a Microsoft Identitásplatform tokenek esetében).

Felhasználótípus-specifikus kockázatcsökkentések

Nem minden felhasználót és alkalmazást érintenek egységesen a külső cookie-k. Vannak olyan esetek, amikor az architektúra vagy az eszközkezelés miatt a jogkivonatok megújítására irányuló csendes hívások harmadik féltől származó cookie-k nélkül is elvégezhetők.

Felügyelt vállalati eszközforgatókönyvek esetén bizonyos böngésző- és platformkombinációk támogatják az eszköz feltételes hozzáférését. Az eszközidentitás alkalmazása minimálisra csökkenti a külső cookie-k szükségességét, mivel a hitelesítési állapot a böngésző helyett az eszközről származhat.

Az Azure AD B2C-alkalmazások esetében az ügyfelek egyéni bejelentkezési tartományt állíthatnak be az alkalmazás tartományának megfelelően. Ebben a forgatókönyvben a böngészők nem tiltanák le a külső cookie-kat, mivel a cookie-k ugyanabban a tartományban maradnak (például login.contoso.com : app.contoso.com).

Az előtérbeli kijelentkezés korlátozása külső cookie-k nélkül

Amikor kijelentkeztet egy felhasználót egy SPA-ból, MSAL.js az előugró vagy átirányítási kijelentkezési módszer használatát javasolja. Bár ez törli a hitelesítési munkamenetet a kiszolgálón és a böngészőtárolóban, fennáll annak a kockázata, hogy a külső cookie-khoz való hozzáférés nélkül nem minden összevont alkalmazás fog egyidejűleg kijelentkezni. Ez az OpenID Front-Channel Logout 1.0 specifikáció ismert korlátozása. Ez azt jelenti a felhasználók számára, hogy az ugyanahhoz a felhasználóhoz tartozó más alkalmazások meglévő hozzáférési jogkivonatai a lejáratukig érvényesek maradnak. A felhasználó kijelentkezhet az A alkalmazásból az A lapon, de a B lapon lévő B alkalmazás továbbra is bejelentkezve jelenik meg a hozzáférési jogkivonat hátralévő érvényes idejére vonatkozóan. Amikor a B alkalmazás jogkivonata lejár, és a rendszer egy új jogkivonat lekérésére kéri a kiszolgálót, a B alkalmazás választ kap a kiszolgálótól, hogy a munkamenet lejárt, és a felhasználót a hitelesítésre kéri.

A Microsoft bejelentkezési oldala és az internetes adatvédelmi ajánlott eljárások azt javasolják, hogy a felhasználók az alkalmazásból való kijelentkezés után zárják be az összes böngészőablakot.

Következő lépések

Az engedélyezési kód folyamatáról és MSAL.js a következő témakörben talál további információt:

• Engedélyezési kódfolyamat.
• MSAL.js 2.0-s rövid útmutató.