Cookieblokkering van derden afhandelen in browsers

Veel browsers blokkeren cookies van derden, cookies op aanvragen naar andere domeinen dan het domein dat wordt weergegeven in de adresbalk van de browser. Deze cookies worden ook wel cookies tussen domeinen genoemd. Dit blok onderbreekt de impliciete stroom en vereist nieuwe verificatiepatronen om gebruikers aan te melden. In het Microsoft Identity Platform gebruiken we de autorisatiestroom met Proof Key for Code Exchange (PKCE) en vernieuwingstokens om gebruikers aangemeld te houden wanneer cookies van derden worden geblokkeerd.

Wat is Intelligent Tracking Protection (ITP) en Privacy Sandbox?

Apple Safari heeft een on-by-default privacybeveiligingsfunctie genaamd Intelligent Tracking Protection of ITP. Chrome heeft een browserprivacyinitiatief met de naam Privacy Sandbox. Deze initiatieven omvatten veel verschillende browserprivacyinspanningen door de browsers en hebben verschillende tijdlijnen. Beide inspanningen blokkeren cookies van derden op aanvragen die meerdere domeinen, met Safari en Brave blokkeren standaard cookies van derden. Chrome heeft onlangs aangekondigd dat ze cookies van derden standaard gaan blokkeren. Privacy Sandbox bevat wijzigingen in gepartitioneerde opslag en cookieblokkering van derden.

Een algemene vorm van het bijhouden van gebruikers wordt uitgevoerd door een iframe op de achtergrond te laden naar een externe site en cookies te gebruiken om de gebruiker via internet te correleren. Helaas is dit patroon ook de standaardmethode voor het implementeren van de impliciete stroom in apps met één pagina (SPA's). Een browser die cookies van derden blokkeert om de privacy van gebruikers te beschermen, kan ook de functionaliteit van een BEVEILIGD-WACHTWOORDVERIFICATIE blokkeren.

De oplossing die in dit artikel wordt beschreven, werkt in al deze browsers of overal waar cookies van derden worden geblokkeerd.

Overzicht van de oplossing

Als u gebruikers in SPA's wilt blijven verifiëren, moeten app-ontwikkelaars de autorisatiecodestroom gebruiken. In de autorisatiecodestroom geeft de id-provider een code uit en wisselt de SPA de code in voor een toegangstoken en een vernieuwingstoken. Wanneer voor de app nieuwe tokens zijn vereist, kan de vernieuwingstokenstroom worden gebruikt om nieuwe tokens op te halen. Microsoft Authentication Library (MSAL) voor JavaScript v2.0 en hoger implementeert de autorisatiecodestroom voor SPA's en is, met kleine updates, een invalvervanging voor MSAL.js 1.x. Zie de migratiehandleiding voor het verplaatsen van een beveiligd-WACHTWOORDVERIFICATIE van impliciete naar verificatiecodestroom.

Voor het Microsoft Identity Platform volgen SPA's en systeemeigen clients vergelijkbare protocolrichtlijnen:

• Gebruik van een PKCE-code-uitdaging
  • PKCE is vereist voor SPA's op het Microsoft Identity Platform. PKCE wordt aanbevolen voor systeemeigen en vertrouwelijke clients.
• Geen gebruik van een clientgeheim

SPA's hebben nog twee beperkingen:

• De omleidings-URI moet worden gemarkeerd als type spa om CORS in te schakelen op aanmeldingseindpunten.
• Vernieuwingstokens die zijn uitgegeven via de autorisatiecodestroom aan spa leiden URI's om en hebben een levensduur van 24 uur in plaats van een levensduur van 90 dagen.

Gevolgen voor prestaties en UX

Sommige toepassingen die gebruikmaken van de impliciete stroom proberen aan te melden zonder omleiding, door een aanmeldings-iframe te openen met behulp van prompt=none. In de meeste browsers reageert deze aanvraag met tokens voor de momenteel aangemelde gebruiker (ervan uitgaande dat toestemming wordt verleend). Dit patroon betekende dat toepassingen geen volledige pagina-omleiding nodig hadden om de gebruiker aan te melden, waardoor de prestaties en gebruikerservaring worden verbeterd. De gebruiker bezoekt de webpagina en is al aangemeld. Omdat prompt=none in een iframe geen optie meer is wanneer cookies van derden worden geblokkeerd, moeten toepassingen hun aanmeldingspatronen aanpassen zodat er een autorisatiecode is uitgegeven.

Zonder cookies van derden zijn er twee manieren om u aan te melden:

• Volledige paginaomleidingen
  • Bij de eerste belasting van de SPA leidt u de gebruiker om naar de aanmeldingspagina als er niet al een sessie bestaat (of als de sessie is verlopen). De browser van de gebruiker bezoekt de aanmeldingspagina, presenteert de cookies met de gebruikerssessie en wordt vervolgens teruggeleid naar de toepassing met de code en tokens in een fragment.
  • De omleiding leidt ertoe dat de SPA tweemaal wordt geladen. Volg de best practices voor het opslaan van SPA's in de cache, zodat de app niet tweemaal volledig wordt gedownload.
  • Overweeg een reeks voor vooraf laden in de app die controleert op een aanmeldingssessie en omleidt naar de aanmeldingspagina voordat de app de JavaScript-payload volledig uitpakt en uitvoert.
• Pop-ups
  • Als de gebruikerservaring (UX) van een volledige paginaomleiding niet werkt voor de toepassing, kunt u overwegen een pop-up te gebruiken om verificatie te verwerken.
  • Wanneer het pop-upvenster na verificatie naar de toepassing is omgeleid, slaat code in de omleidingshandler de verificatiecode op en worden tokens opgeslagen in de lokale opslag die de toepassing kan gebruiken. MSAL.js ondersteunt pop-ups voor verificatie, net zoals de meeste bibliotheken.
  • Browsers verlagen de ondersteuning voor pop-ups, zodat ze mogelijk niet de meest betrouwbare optie zijn. Gebruikersinteractie met de BEVEILIGD-WACHTWOORDVERIFICATIE voordat u de pop-up maakt, is mogelijk nodig om te voldoen aan de vereisten van de browser.

Apple beschrijft een pop-upmethode als een tijdelijke compatibiliteitsoplossing om het oorspronkelijke venster toegang te geven tot cookies van derden. Hoewel Apple deze overdracht van machtigingen in de toekomst kan verwijderen, heeft dit hier geen invloed op de richtlijnen.

Hier wordt de pop-up gebruikt als een eerste partijnavigatie naar de aanmeldingspagina, zodat er een sessie wordt gevonden en er een verificatiecode kan worden opgegeven. Dit zou in de toekomst moeten blijven werken.

Ontwikkelaars kunnen blijven gebruiken prompt=none met de verwachting dat ze een hoger aantal interacion_required fouten zien wanneer cookies van derden worden geblokkeerd. De aanbeveling is altijd een interactieve methode terugval te hebben als er fouten optreden tijdens het verkrijgen van tokens op de achtergrond.

iframes gebruiken

Een veelvoorkomend patroon in web-apps is het gebruik van een iframe om een app in te sluiten in een andere: het frame op het hoogste niveau verwerkt de verificatie van de gebruiker en de toepassing die wordt gehost in het iframe, kan vertrouwen dat de gebruiker is aangemeld en tokens op de achtergrond ophaalt met behulp van de impliciete stroom. Er zijn echter enkele opmerkingen bij deze aanname, ongeacht of cookies van derden zijn ingeschakeld of geblokkeerd in de browser.

Het verkrijgen van stille tokens werkt niet meer wanneer cookies van derden worden geblokkeerd. De toepassing die is ingesloten in het iframe, moet overschakelen naar pop-ups om toegang te krijgen tot de sessie van de gebruiker, omdat deze niet naar de aanmeldingspagina binnen een ingesloten frame kan navigeren.

U kunt eenmalige aanmelding bereiken tussen iframed- en bovenliggende apps met JavaScript-script API-toegang van dezelfde oorsprong en meerdere oorsprongen door een hint van de gebruiker (account) van de bovenliggende app door te geven aan de iframed-app. Zie MSAL.js gebruiken in iframed-apps in de MSAL.js-opslagplaats op GitHub voor meer informatie.

Beveiligingsimplicaties van vernieuwingstokens in de browser

XSS-aanvallen (script uitvoeren op meerdere sites) of gecompromitteerde JS-pakketten kunnen het vernieuwingstoken stelen en op afstand gebruiken totdat het verloopt of wordt ingetrokken. Toepassingsontwikkelaars zijn verantwoordelijk voor het verminderen van het risico van het uitvoeren van scripts op meerdere sites. Om het risico op gestolen vernieuwingstokens te minimaliseren, zijn SPA's slechts 24 uur geldig. Na 24 uur moet de app een nieuwe autorisatiecode verkrijgen via een frame op het hoogste niveau naar de aanmeldingspagina.

Dit vernieuwingstokenpatroon met een beperkte levensduur is gekozen als een evenwicht tussen beveiliging en verslechterde UX. Zonder vernieuwingstokens of cookies van derden wordt de autorisatiecodestroom (zoals aanbevolen door het concept van de huidige best practices voor OAuth-beveiliging) onopgemerkt wanneer nieuwe of aanvullende tokens vereist zijn. Er is een volledige paginaomleiding of pop-up nodig voor elk token, telkens wanneer een token verloopt (meestal elk uur voor de Microsoft Identity Platform-tokens).

Specifieke oplossingen voor gebruikerstypen

Niet alle gebruikers en toepassingen worden uniform beïnvloed door cookies van derden. Er zijn enkele scenario's waarbij vanwege architectuur of apparaatbeheer stille aanroepen om tokens te vernieuwen kunnen worden uitgevoerd zonder cookies van derden.

Voor scenario's voor beheerde bedrijfsapparaten hebben bepaalde combinaties van browsers en platformen ondersteuning voor voorwaardelijke toegang van apparaten. Het toepassen van apparaat-id minimaliseert de noodzaak van cookies van derden, omdat de verificatiestatus van het apparaat afkomstig kan zijn in plaats van de browser.

Voor Azure AD B2C-toepassingsscenario's kunnen klanten een aangepast aanmeldingsdomein instellen dat overeenkomt met het domein van de toepassing. Browsers blokkeren in dit scenario geen cookies van derden, omdat de cookies in hetzelfde domein blijven (bijvoorbeeld login.contoso.com aan app.contoso.com).

Beperkingen voor afmelding van front-channel zonder cookies van derden

Wanneer u een gebruiker afmeldt bij een beveiligd-WACHTWOORDVERIFICATIE, wordt MSAL.js aangeraden de aanmeldingsmethode voor pop-up of omleiding te gebruiken. Hoewel hiermee de verificatiesessie op de server en in de browseropslag wordt gewist, is er een risico dat zonder toegang tot cookies van derden, niet alle federatieve toepassingen tegelijkertijd een afmelding zien. Dit is een bekende beperking van de OpenID Front-Channel Logout 1.0 specificatie. Wat dit betekent voor gebruikers is dat bestaande toegangstokens voor andere toepassingen voor dezelfde gebruiker geldig blijven tot hun verlooptijd. Een gebruiker kan zich afmelden bij toepassing A in tabblad A, maar toepassing B in tabblad B wordt nog steeds weergegeven als aangemeld voor de resterende geldige tijd van het toegangstoken. Wanneer het token van toepassing B verloopt en er een aanroep naar de server wordt gedaan om een nieuw token op te halen, ontvangt toepassing B een antwoord van de server waarop de sessie is verlopen en vraagt de gebruiker om zich te verifiëren.

De afmeldingspagina en aanbevolen procedures voor internetprivacy van Microsoft raden gebruikers aan alle browservensters te sluiten nadat ze zich hebben afgemeld bij een toepassing.

Volgende stappen

Zie voor meer informatie over autorisatiecodestroom en MSAL.js:

• Stroom voor autorisatiecode.
• MSAL.js 2.0-quickstart.