Share via

Hantera cookieblockering från tredje part i webbläsare

  • Artikel

Många webbläsare blockerar cookies från tredje part, cookies på begäranden till andra domäner än domänen som visas i webbläsarens adressfält. Dessa cookies kallas även för korsdomäncookies. Det här blocket bryter det implicita flödet och kräver nya autentiseringsmönster för att kunna logga in användare. I Microsofts identitetsplattform använder vi auktoriseringsflödet med Proof Key for Code Exchange (PKCE) och uppdateringstoken för att hålla användarna inloggade när cookies från tredje part blockeras.

Vad är Intelligent Tracking Protection (ITP) och Privacy Sandbox?

Apple Safari har en sekretessskyddsfunktion som standard som kallas Intelligent Tracking Protection eller ITP. Chrome har ett webbläsarintegritetsinitiativ med namnet Privacy Sandbox. Dessa initiativ omfattar många olika webbläsarsekretessinsatser i webbläsaren och har olika tidslinjer. Båda insatserna blockerar cookies från tredje part på begäranden som korsar domäner, där Safari och Brave blockerar cookies från tredje part som standard. Chrome meddelade nyligen att de kommer att börja blockera cookies från tredje part som standard. Sandbox-miljön för sekretess innehåller ändringar i partitionerad lagring samt cookieblockering från tredje part.

En vanlig form av användarspårning görs genom att läsa in en iframe till en webbplats från tredje part i bakgrunden och använda cookies för att korrelera användaren via Internet. Tyvärr är det här mönstret också standardsättet för att implementera det implicita flödet i ensidesappar (SPA). En webbläsare som blockerar cookies från tredje part för att skydda användarsekretessen kan också blockera funktionerna i ett SPA.

Lösningen som beskrivs i den här artikeln fungerar i alla dessa webbläsare, eller någonstans där cookies från tredje part blockeras.

Översikt över lösningen

För att kunna fortsätta autentisera användare i SPA:er måste apputvecklare använda auktoriseringskodflödet. I autentiseringskodflödet utfärdar identitetsprovidern en kod och SPA löser in koden för en åtkomsttoken och en uppdateringstoken. När appen kräver nya token kan den använda flödet för uppdateringstoken för att hämta nya token. Microsoft Authentication Library (MSAL) för JavaScript v2.0 och senare implementerar auktoriseringskodflödet för SPA:er och, med mindre uppdateringar, är en drop-in ersättning för MSAL.js 1.x. Se migreringsguiden för att flytta ett SPA från implicit till autentiseringskodflöde.

För Microsofts identitetsplattform följer SPA:erna och interna klienter liknande protokollvägledning:

  • Användning av en PKCE-kodutmaning
    • PKCE krävs för SPA:er på Microsofts identitetsplattform. PKCE rekommenderas för interna och konfidentiella klienter.
  • Ingen användning av en klienthemlighet

SPA:er har ytterligare två begränsningar:

  • Omdirigerings-URI:n måste markeras som typ spa för att aktivera CORS på inloggningsslutpunkter.
  • Uppdateringstoken som utfärdas via auktoriseringskodflödet för att spa omdirigera URI:er har en livslängd på 24 timmar i stället för en livslängd på 90 dagar.

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

Prestanda- och UX-konsekvenser

Vissa program som använder implicit flöde försöker logga in utan att omdirigera genom att öppna en inloggnings-iframe med .prompt=none I de flesta webbläsare svarar den här begäran med token för den inloggade användaren (förutsatt att medgivande beviljas). Det här mönstret innebar att program inte behövde en fullständig sidomdirigering för att logga in användaren, vilket förbättrade prestanda och användarupplevelse – användaren besöker webbsidan och är redan inloggad. Eftersom prompt=none i en iframe inte längre är ett alternativ när cookies från tredje part blockeras, måste program justera sina inloggningsmönster för att få en auktoriseringskod utfärdad.

Utan cookies från tredje part finns det två sätt att utföra inloggning:

  • Omdirigeringar för hela sidan
    • Vid den första inläsningen av SPA omdirigerar du användaren till inloggningssidan om det inte redan finns någon session (eller om sessionen har upphört att gälla). Användarens webbläsare besöker inloggningssidan, visar cookies som innehåller användarsessionen och omdirigeras sedan tillbaka till programmet med koden och token i ett fragment.
    • Omdirigeringen resulterar i att SPA läses in två gånger. Följ metodtipsen för cachelagring av SPA:er så att appen inte laddas ned i sin helhet två gånger.
    • Överväg att ha en förinläsningssekvens i appen som söker efter en inloggningssession och omdirigerar till inloggningssidan innan appen helt packar upp och kör JavaScript-nyttolasten.
  • Popups
    • Om användarupplevelsen (UX) för en fullständig sidomdirigering inte fungerar för programmet kan du överväga att använda ett popup-fönster för att hantera autentisering.
    • När popup-fönstret har omdirigerats till programmet efter autentiseringen lagrar kod i omdirigeringshanteraren autentiseringskoden och token i lokal lagring som programmet ska använda. MSAL.js stöder popup-fönster för autentisering, liksom de flesta bibliotek.
    • Webbläsare minskar stödet för popup-fönster, så de kanske inte är det mest tillförlitliga alternativet. Användarinteraktion med SPA innan du skapar popup-fönstret kan behövas för att uppfylla webbläsarkraven.

Apple beskriver en popup-metod som en tillfällig kompatibilitetskorrigering för att ge det ursprungliga fönstret åtkomst till cookies från tredje part. Apple kan ta bort denna överföring av behörigheter i framtiden, men det påverkar inte vägledningen här.

Här används popup-fönstret som en förstapartsnavigering till inloggningssidan så att en session hittas och en autentiseringskod kan anges. Detta bör fortsätta att arbeta in i framtiden.

Utvecklare kan fortsätta att använda prompt=none med förväntan att de ser en högre frekvens av interacion_required fel när cookies från tredje part blockeras. Rekommendationen är att alltid ha en interaktiv metodåterställning om fel uppstår vid tyst tokeninsamling.

Använda iframes

Ett vanligt mönster i webbappar är att använda en iframe för att bädda in en app i en annan: ramen på den översta nivån hanterar autentiseringen av användaren och programmet som finns i iframe kan lita på att användaren är inloggad och hämtar token tyst med det implicita flödet. Det finns dock ett par förbehåll för detta antagande oavsett om cookies från tredje part är aktiverade eller blockerade i webbläsaren.

Tyst tokenhämtning fungerar inte längre när cookies från tredje part blockeras – programmet som är inbäddat i iframe måste växla till att använda popup-fönster för att få åtkomst till användarens session eftersom det inte kan navigera till inloggningssidan i en inbäddad ram.

Du kan uppnå enkel inloggning mellan iframed och överordnade appar med javaScript-skript-API-åtkomst med samma ursprung och korsande ursprung genom att skicka ett användartips (konto) från den överordnade appen till den iframerade appen. Mer information finns i Använda MSAL.js i iframade appar på MSAL.js-lagringsplatsen på GitHub.

Säkerhetskonsekvenser av uppdateringstoken i webbläsaren

XSS-attacker (cross-site scripting) eller komprometterade JS-paket kan stjäla uppdateringstoken och använda den via fjärranslutning tills den upphör att gälla eller återkallas. Programutvecklare ansvarar för att minska risken för skript mellan webbplatser. För att minimera risken för stulna uppdateringstoken utfärdas endast token som är giltiga i 24 timmar. Efter 24 timmar måste appen skaffa en ny auktoriseringskod via ett rambesök på den översta nivån på inloggningssidan.

Det här mönstret för uppdateringstoken med begränsad livslängd valdes som en balans mellan säkerhet och degraderat UX. Utan uppdateringstoken eller cookies från tredje part blir auktoriseringskodflödet (enligt rekommendationerna i utkastet till bästa praxis för OAuth-säkerhet) betungande när nya eller ytterligare token krävs. En fullständig sidomdirigering eller popup-meny krävs för varje enskild token, varje gång en token upphör att gälla (varje timme vanligtvis för Microsofts identitetsplattform token).

Specifika åtgärder för användartyp

Alla användare och program påverkas inte på samma sätt av cookies från tredje part. Det finns vissa scenarier där tysta samtal för att förnya token kan göras utan cookies från tredje part på grund av arkitektur eller enhetshantering.

För scenarier med hanterade företagsenheter har vissa webbläsar- och plattformskombinationer stöd för enhets villkorlig åtkomst. Genom att använda enhetsidentitet minimeras behovet av cookies från tredje part eftersom autentiseringstillståndet kan komma från enheten i stället för webbläsaren.

För Azure AD B2C-programscenarier kan kunder konfigurera en anpassad inloggningsdomän som matchar programmets domän. Webbläsare skulle inte blockera cookies från tredje part i det här scenariot eftersom cookies finns kvar i samma domän (t.ex. login.contoso.com till app.contoso.com).

Begränsningar för utloggning i Front-Channel utan cookies från tredje part

När du loggar ut en användare från ett SPA rekommenderar MSAL.js att du använder utloggningsmetoden för popup- eller omdirigering. Detta rensar autentiseringssessionen på servern och i webbläsarens lagring, men det finns en risk att inte alla federerade program ser en utloggning samtidigt utan åtkomst till cookies från tredje part. Detta är en känd begränsning i OpenID Front-Channel Logout 1.0-specifikationen. Vad detta innebär för användare är att befintliga åtkomsttoken för andra program för samma användare fortsätter att vara giltiga tills de upphör att gälla. En användare kan logga ut från program A på fliken A, men program B på fliken B visas fortfarande som inloggad för den återstående giltiga tiden för åtkomsttoken. När program B:s token upphör att gälla och ett anrop görs till servern för att hämta en ny token, får program B ett svar från servern om att sessionen har upphört att gälla och uppmanar användaren att autentisera.

Microsofts metodtips för utloggningssida och internetsekretess rekommenderar att användarna stänger alla webbläsarfönster när de har loggat ut från ett program.

Nästa steg

Mer information om auktoriseringskodflöde och MSAL.js finns i: