Hantera ITP i Safari och andra webbläsare där cookies från tredje part blockeras

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. 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)?

Apple Safari har en standardfunktion för integritetsskydd som kallas Intelligent Tracking Protection eller ITP. ITP blockerar cookies från tredje part, cookies på begäranden mellan domäner.

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 över Internet. Tyvärr är det här mönstret också standardsättet för att implementera det implicita flödet i ensidesappar (SPA). När en webbläsare blockerar cookies från tredje part för att förhindra användarspårning bryts även SPA:erna.

Safari är inte ensamt om att blockera cookies från tredje part för att förbättra användarsekretessen. Brave blockerar cookies från tredje part som standard, och Chromium (plattformen bakom Google Chrome och Microsoft Edge) har meddelat att de också kommer att sluta stödja cookies från tredje part i framtiden.

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

Om du vill 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 ytterligare 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 implementerar auktoriseringskodflödet för SPA:erna och, med mindre uppdateringar, är en drop-in ersättning för MSAL.js 1.x.

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

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

SPA:erna 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 som visar OAuth 2-auktoriseringskodflödet mellan en ensidesapp och tjänstslutpunkten för säkerhetstoken.

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 redan har beviljats). 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 besöka inloggningssidan i en ram på den översta nivån för att en auktoriseringskod ska utfärdas.

Det finns två sätt att utföra inloggning:

  • Omdirigeringar för hela sidan
    • Vid den första inläsningen av SPA:n 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, presenterar cookies som innehåller användarsessionen och omdirigerar sedan tillbaka till programmet med koden och token i ett fragment.
    • Omdirigeringen resulterar i att SPA:et läses in två gånger. Följ metodtipsen för cachelagring av SPA 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.
  • Popup-fönster
    • 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 koden 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äsarens krav.

      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. Även om Apple kan ta bort denna överföring av behörigheter i framtiden påverkar det 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 tillhandahållas. Detta bör fortsätta att fungera in i framtiden.

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 autentisering 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.

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.

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 iframed appen. Mer information finns i Använda MSAL.js i iframed-appar på MSAL.js-lagringsplatsen på GitHub.

Säkerhetskonsekvenser av uppdateringstoken i webbläsaren

Att utfärda uppdateringstoken till webbläsaren anses vara ett säkerhetsproblem. 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. För att minimera risken för stulna uppdateringstoken kommer SPA:erna endast att utfärdas som giltiga i 24 timmar. Efter 24 timmar måste appen hämta 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 (som rekommenderas av 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 token, varje gång en token upphör att gälla (vanligtvis varje timme för Microsofts identitetsplattform token).

Nästa steg

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