Teilen über

So werden Cookies von Drittanbietern in Browsern blockiert

  • Artikel

Viele Browser blockieren Cookies von Drittanbietern, Cookies bei Anforderungen an andere Domänen als die Domäne, die in der Adressleiste des Browsers angezeigt wird. Diese Cookies werden auch als domänenübergreifende Cookies bezeichnet. Durch den Block wird der implizite Fluss unterbrochen, und es sind neue Authentifizierungsmuster erforderlich, um Benutzer erfolgreich anzumelden. In der Microsoft-Identitätsplattform verwenden wir den Autorisierungsfluss mit Proof Key for Code Exchange (PKCE) und Refresh-Tokens, um die Anmeldung von Benutzern aufrechtzuerhalten, wenn Cookies von Drittanbietern blockiert werden. Dieser Autorisierungscodefluss mit Proof Key für den Code Exchange-Ansatz wird über den impliziten Fluss empfohlen.

Was ist Intelligent Tracking Protection (ITP) und die Privacy Sandbox?

Apple Safari verfügt über eine standardmäßig aktivierte Datenschutzfunktion namens Intelligent Tracking Prevention oder ITP. Chrome verfügt über eine Browserdatenschutzinitiative namens Privacy Sandbox. Diese Initiativen umfassen viele verschiedene Browserdatenschutzbemühungen durch die Browser und haben unterschiedliche Zeitachsen. Beide Methoden blockieren Cookies von Drittanbietern bei domänenübergreifenden Anforderungen. Safari und Brave blockieren Cookies von Drittanbietern standardmäßig. Chrome hat kürzlich angekündigt, dass das standardmäßige Blockieren von Drittanbietercookies gestartet wird. Die Privacy Sandbox umfasst Änderungen am partitionierten Speicher sowie die Blockierung von Cookies von Drittanbietern.

Eine gängige Form der Benutzernachverfolgung erfolgt durch das Laden eines IFrames auf eine Drittanbieterwebsite im Hintergrund und das Verwenden von Cookies, um den Benutzer über das Internet zu korrelieren. Leider handelt es sich bei diesem Muster auch um die Standardmethode für das Implementieren des impliziten Flusses in Single-Page-Webanwendungen (Single-Page Apps, SPAs). Ein Browser, der Cookies von Drittanbietern blockiert, um die Privatsphäre der Benutzer zu schützen, kann auch die Funktionalität einer SPA blockieren. Die Verwendung des impliziten Flusses in SPAs wird aufgrund der Blockierung von Drittanbieter-Cookies und den damit verbundenen Sicherheitsrisiken nicht mehr empfohlen.

Die in diesem Artikel beschriebene Lösung funktioniert in all diesen Browsern bzw. überall, wo Cookies von Drittanbietern blockiert werden.

Übersicht über die Lösung

Damit Benutzer in SPAs weiterhin authentifiziert werden können, müssen App-Entwickler den Autorisierungscode-Flow verwenden. Im Autorisierungscode-Flow gibt der Identitätsanbieter einen Code aus, und die SPA löst den Code für ein Zugriffstoken und ein Aktualisierungstoken ein. Wenn die App neue Token benötigt, kann sie den Aktualisierungstoken-Flow zum Abrufen neuer Token verwenden. Microsoft Authentication Library (MSAL) für JavaScript v2.0 und höher implementiert den Autorisierungscodefluss für SPA und ist, mit kleineren Updates, ein direkter Ersatz für MSAL.js 1.x. Lesen Sie den Migrationsleitfaden zum Verschieben einer SPA von implizitem zu Authentifizierungscode-Flow.

In Bezug auf die Microsoft Identity Platform gelten für SPAs und native Clients ähnliche Protokollleitlinien:

  • Verwendung einer PKCE-Code-Captcha
    • PKCE ist für SPAs auf der Microsoft Identity Platform erforderlich. Für native und vertrauliche Clients wird PKCE empfohlen.
  • Keine Verwendung eines geheimen Clientschlüssels

Für SPAs gelten zwei weitere Einschränkungen:

Diagramm des OAuth 2-Autorisierungscode-Flows zwischen einer Single-Page-Webanwendung und dem Endpunkt des Sicherheitstokendiensts.

Auswirkungen auf die Leistung und Benutzerfreundlichkeit

Einige Anwendungen, die den impliziten Fluss verwenden, versuchen, sich ohne Umleitung anzumelden, indem sie einen Anmelde-IFrame mit prompt=none öffnen. In den meisten Browsern reagiert diese Anforderung mit Token für den aktuell angemeldeten Benutzer (vorausgesetzt, die Einwilligung wurde bereits erteilt). Dieses Muster bedeutete, dass Anwendungen keine vollständige Seitenumleitung benötigten, um den Benutzer anzumelden, was die Leistung und die Benutzerfreundlichkeit verbesserte - der Benutzer besucht die Webseite und ist bereits angemeldet. Weil prompt=none in einem IFrame keine Option mehr ist, wenn Cookies von Drittanbietern blockiert werden, müssen Anwendungen ihre Anmeldemuster so aktualisieren, dass ein Autorisierungscode ausgegeben wird.

Es gibt zwei Möglichkeiten, die Anmeldung ohne Cookies von Drittanbietern vorzunehmen:

  • Vollständige Seitenumleitungen
    • Leiten Sie den Benutzer beim ersten Laden der SPA auf die Anmeldeseite um, wenn noch keine Sitzung vorhanden ist (oder wenn die Sitzung abgelaufen ist). Der Browser des Benutzers ruft die Anmeldeseite auf, zeigt die Cookies an, die die Benutzersitzung enthalten, und wird dann mit dem Code und den Token in einem Fragment zurück zur Anwendung geleitet.
    • Die Umleitung führt dazu, dass die SPA zweimal geladen wird. Befolgen Sie die Best Practices für die Zwischenspeicherung von SPAs, damit die App nicht zweimal vollständig heruntergeladen wird.
    • Ziehen Sie in Erwägung, eine Vorladesequenz in der Anwendung zu verwenden, die auf das Vorhandensein einer Anmeldesitzung prüft und auf die Anmeldeseite umleitet, bevor die App vollständig entpackt wird und die JavaScript-Nutzlast ausführt.
  • Popups
    • Wenn die Benutzerfreundlichkeit (UX) einer vollständigen Seitenumleitung für die Anwendung nicht funktioniert, empfiehlt sich die Verwendung eines Popups für die Authentifizierung.
    • Wenn das Popup die Umleitung zur Anwendung nach der Authentifizierung beendet, speichert der Code im Umleitungshandler den Authentifizierungscode und die Token im lokalen Speicher, damit die Anwendung sie verwenden kann. MSAL.js unterstützt Popups für die Authentifizierung, wie die meisten Bibliotheken.
    • Die Unterstützung von Popups in Browsern nimmt ab, daher stellen sie möglicherweise nicht die zuverlässigste Option dar. Möglicherweise ist eine Benutzerinteraktion mit der SPA vor dem Erstellen des Popups erforderlich, um die Browseranforderungen zu erfüllen.

Apple beschreibt eine Popupmethode als temporäre Kompatibilitätskorrektur, um dem ursprünglichen Fenster Zugriff auf Cookies von Drittanbietern zu ermöglichen. Auch wenn Apple diese Übertragung von Berechtigungen in Zukunft möglicherweise nicht mehr zulässt, hat das keine Auswirkungen auf die vorliegende Anleitung.

Hier wird das Pop-Up als Erstnavigation zur Anmeldeseite verwendet, sodass eine Sitzung gefunden wird und ein Autorisierungscode bereitgestellt werden kann. Dies sollte auch in Zukunft weiterhin funktionieren.

Entwickler können weiterhin prompt=none mit der Erwartung verwenden, dass sie eine höhere Rate von interacion_required-Fehlern sehen, wenn Cookies von Drittanbietern blockiert werden. Die Empfehlung besteht darin, immer einen Rückgriff auf interaktive Methoden zu haben, wenn Fehler während der automatischen Token-Erfassung auftreten.

Verwenden von iframes

Ein gängiges Muster in Web-Apps ist die Verwendung eines IFrames zum Einbetten einer App in eine andere: Der Frame der obersten Ebene übernimmt die Authentifizierung des Benutzers, und die im iFrame gehostete Anwendung kann darauf vertrauen, dass der Benutzer angemeldet ist, da Token im Hintergrund mithilfe des impliziten Flows abgerufen werden. Es gibt jedoch einige Vorbehalte für diese Annahme, und zwar unabhängig davon, ob Cookies von Drittanbietern im Browser aktiviert oder blockiert sind.

Das automatische Abrufen von Tokens funktioniert nicht mehr, wenn Drittanbieter-Cookies blockiert werden. Die in den IFrame eingebettete Anwendung muss auf die Verwendung von Pop-Ups umstellen, um auf die Sitzung des Benutzers zuzugreifen, weil sie nicht zur Anmeldeseite mit einem eingebetteten Frame navigieren kann.

Sie können Single Sign-On zwischen iframierten und übergeordneten Apps mit JavaScript-Skript-API-Zugriff mit gleichem Ursprung und ursprungsübergreifendem JavaScript-Skript erreichen, indem Sie einen Benutzerhinweis (Konto) von der übergeordneten App an die App übergeben. Weitere Informationen finden Sie unter Using MSAL.js in iframed apps im MSAL.js-Repository auf GitHub.

Sicherheitsaspekte von Aktualisierungstoken im Browser

Angriffe durch websiteübergreifendes Skripting (Cross-Site Scripting, XSS) oder kompromittierte JS-Pakete können das Aktualisierungstoken stehlen und es remote verwenden, bis es abläuft oder widerrufen wird. Anwendungsentwickler sind dafür verantwortlich, das Risiko ihrer Anwendung für Cross-Site Scripting zu verringern. Um das Risiko durch gestohlene Aktualisierungstoken zu minimieren, werden für SPA nur Tokens ausgestellt, die nur 24 Stunden gültig sind. Nach 24 Stunden muss die App durch Aufrufen der Anmeldeseite in einem Frame der obersten Ebene einen neuen Autorisierungscode abrufen.

Dieses Muster für Aktualisierungstoken mit begrenzter Lebensdauer wurde als Kompromiss zwischen Sicherheit und verminderter Benutzerfreundlichkeit ausgewählt. Ohne Aktualisierungstoken oder Cookies von Drittanbietern wird der Autorisierungscodeflow (wie im Entwurf der aktuellen bewährten Sicherheitsverfahren für OAuth empfohlen) aufwändig, wenn neue oder zusätzliche Token erforderlich sind. Jedes Mal, wenn ein Token abläuft (bei Microsoft Identity Platform-Token normalerweise stündlich) ist eine vollständige Seitenumleitung oder ein Popup für jedes einzelne Token erforderlich.

Benutzertypspezifische Risikominderungen

Nicht alle Benutzer und Anwendungen sind von Cookies von Drittanbietern einheitlich betroffen. Es gibt einige Szenarien, in denen aufgrund der Architektur oder Geräteverwaltung automatische Aufrufe zur Verlängerung von Token ohne Cookies von Drittanbietern ausgeführt werden können.

Für Szenarien mit verwalteten Unternehmensgeräten haben bestimmte Browser- und Plattformkombinationen Unterstützung für gerätebedingten Zugriff. Das Anwenden der Geräte-ID minimiert die Notwendigkeit von Cookies von Drittanbietern, da der Authentifizierungsstatus vom Gerät anstelle des Browsers stammen kann.

Für Azure AD B2C-Anwendungsszenarien können Kunden eine benutzerdefinierte Anmeldedomäne einrichten, die der Anwendungsdomäne entspricht. Browser würden Cookies von Drittanbietern in diesem Szenario nicht blockieren, da die Cookies in derselben Domäne verbleiben (z.B. login.contoso.com zu app.contoso.com).

Einschränkungen bei der Frontkanalabmeldung ohne Cookies von Drittanbietern

Bei der Abmeldung eines Benutzers von einer SPA empfiehlt MSAL.js die Verwendung der Popup- oder Umleitungsabmeldungsmethode. Dies löscht zwar die Authentifizierungssitzung auf dem Server und im Browserspeicher, aber es besteht ein Risiko, dass ohne Zugriff auf Cookies von Drittanbietern nicht bei allen Verbundanwendungen gleichzeitig eine Abmeldung erfolgt. Dies ist eine bekannte Einschränkung der OpenID Front-Channel Logout 1.0-Spezifikation. Dies bedeutet für Benutzer, dass vorhandene Zugriffstoken für andere Anwendungen für denselben Benutzer bis zur Ablaufzeit weiterhin gültig sind. Ein Benutzer kann sich also von Anwendung A in Tab A abmelden, die Anwendung B wird in Tab B jedoch weiterhin für die verbleibende Gültigkeitsdauer des Zugriffstokens als angemeldet angezeigt. Wenn das Token von Anwendung B abläuft und ein Aufruf an den Server erfolgt, um ein neues Token abzurufen, empfängt die Anwendung B eine Antwort vom Server, dass die Sitzung abgelaufen ist, und fordert den Benutzer auf, sich zu authentifizieren.

Die Anmeldeseite von Microsoft und die bewährten Methoden für den Internetdatenschutz empfehlen, alle Browserfenster nach der Abmeldung einer Anwendung zu schließen.

Nächste Schritte

Weitere Informationen zum Autorisierungscode-Flow und MSAL.js finden Sie unter: