Auswirkungen der Änderungen an Drittanbieter-Cookies auf Ihre Anmeldeworkflows prüfen

bookmark_border Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Chrome bietet Nutzern eine neue Möglichkeit, Drittanbieter-Cookies zu aktivieren oder zu deaktivieren. Sie müssen Ihre Website für Nutzer vorbereiten, die ohne Drittanbieter-Cookies surfen möchten.

Auf dieser Seite finden Sie Informationen zu den Identitätsszenarien, die am ehesten betroffen sind, sowie Verweise auf mögliche Lösungen.

Wenn Ihre Website nur Aufrufe innerhalb derselben Domain und Subdomains verarbeitet, z. B. publisher.example und login.publisher.example, werden keine websiteübergreifenden Cookies verwendet. Die Anmeldung wird voraussichtlich nicht von Änderungen an Drittanbieter-Cookies betroffen sein.

Wenn auf Ihrer Website jedoch eine separate Domain für die Anmeldung verwendet wird, z. B. mit der Google-Anmeldung oder der Facebook-Anmeldung, oder die Nutzerauthentifizierung auf Ihrer Website für mehrere Domains oder Subdomains freigegeben werden muss, müssen Sie möglicherweise Änderungen an Ihrer Website vornehmen, um eine reibungslose Umstellung von websiteübergreifenden Cookies zu ermöglichen.

Häufige Kaufprozesse

Bisher beruhten viele Identitätsworkflows auf Drittanbieter-Cookies. In der Tabelle finden Sie einige gängige User Journeys und mögliche Lösungen für diese, die nicht von Drittanbieter-Cookies abhängen. In den folgenden Abschnitten werden die Gründe für diese Empfehlungen erläutert.

Empfohlene alternative APIs für gängige Anwendungsfälle

gekennzeichnet sind

in der Tabelle befinden sich in der Anfangsphase ihrer Entwicklung. Dein Feedback ist wertvoll und hilft uns, die Zukunft von YouTube zu gestalten. Teilen Sie uns Ihre Meinung zu diesen APIs mit: Partitionierte Pop-ups.

Identitätsbezogene User Journeys testen

Am besten testen Sie, ob sich die Änderungen an Drittanbieter-Cookies auf die Anmeldung auswirken, indem Sie die Registrierung, Passwortwiederherstellung, Anmeldung und Abmeldung mit aktiviertem Testflag für Drittanbieter-Cookies durchlaufen.

Hier finden Sie eine Checkliste mit Dingen, die Sie prüfen sollten, nachdem Sie Drittanbieter-Cookies eingeschränkt haben:

• Nutzerregistrierung:Das Erstellen eines neuen Kontos funktioniert wie erwartet. Wenn Sie Identitätsanbieter von Drittanbietern verwenden, prüfen Sie, ob die Registrierung neuer Konten für jede Integration funktioniert.
• Passwortwiederherstellung:Die Passwortwiederherstellung funktioniert wie erwartet, von der Web-UI über CAPTCHAs bis zum Empfang der E-Mail zur Passwortwiederherstellung.
• Anmeldung:Der Anmeldevorgang funktioniert innerhalb derselben Domain und beim Aufrufen anderer Domains. Denken Sie daran, jede Anmeldeintegration zu testen.
• Abmeldung:Die Abmeldung funktioniert wie erwartet und der Nutzer bleibt nach dem Abmeldevorgang abgemeldet.

Sie sollten auch testen, ob andere Websitefunktionen, für die eine Nutzeranmeldung erforderlich ist, ohne websiteübergreifende Cookies funktionieren, insbesondere wenn websiteübergreifende Ressourcen geladen werden. Wenn Sie beispielsweise ein CDN zum Laden von Nutzerprofilbildern verwenden, prüfen Sie, ob dies weiterhin funktioniert. Wenn kritische User Journeys wie der Bezahlvorgang an eine Anmeldung gebunden sind, müssen Sie dafür sorgen, dass sie weiterhin funktionieren.

Anmeldelösungen

In diesem Abschnitt finden Sie genauere Informationen dazu, wie sich diese Änderungen auf diese Zugriffe auswirken könnten.

Einmalanmeldung (SSO) von Drittanbietern

Mit der Einmalanmeldung (SSO) von Drittanbietern können sich Nutzer mit einem einzigen Anmeldedatensatz auf einer Plattform authentifizieren und dann auf mehrere Anwendungen und Websites zugreifen, ohne ihre Anmeldedaten noch einmal eingeben zu müssen. Aufgrund der Komplexität der Implementierung einer SSO-Lösung entscheiden sich viele Unternehmen für die Nutzung eines Drittanbieters, um den Anmeldestatus für mehrere Ursprünge freizugeben. Beispiele für Anbieter sind Okta, Ping Identity, Google Cloud IAM oder Microsoft Entra ID.

Wenn Ihre Lösung auf einem Drittanbieter basiert, sind möglicherweise einige kleinere Änderungen erforderlich, z. B. ein Bibliotheksupgrade. Am besten wenden Sie sich an den Anbieter, um herauszufinden, wie sich Drittanbieter-Cookie-Abhängigkeiten auf die Lösung auswirken und welchen Ansatz er für seinen Dienst empfiehlt. Einige Anbieter migrieren geräuschlos zu anderen Technologien. In diesem Fall müssen die entsprechenden Seiten nicht aktualisiert werden.

Mehrere Domains

Einige Websites verwenden eine andere Domain nur für die Authentifizierung von Nutzern, die nicht für Cookies derselben Website infrage kommen. Das ist beispielsweise bei einer Website der Fall, die example.com für die Hauptwebsite und login.example für den Anmeldevorgang verwendet. Hier ist möglicherweise der Zugriff auf Drittanbieter-Cookies erforderlich, damit der Nutzer in beiden Domains authentifiziert werden kann.

Einige Unternehmen haben mehrere Produkte, die auf verschiedenen Domains oder Subdomains gehostet werden. Bei solchen Lösungen kann es sinnvoll sein, die Nutzersitzung für diese Produkte zu teilen. In diesem Fall ist möglicherweise der Zugriff auf Drittanbieter-Cookies zwischen mehreren Domains erforderlich.

Mögliche Migrationspfade für dieses Szenario:

• Aktualisierung zur Verwendung von eigenen („SameSite“) Cookies:Ändern Sie die Websiteinfrastruktur so, dass der Anmeldevorgang in derselben Domain (oder einer Subdomain) wie die Hauptwebsite gehostet wird. Dabei werden nur eigene Cookies verwendet. Je nach Infrastruktur kann dies mehr Aufwand erfordern.
• Related Website Sets (RWS) und Storage Access API (SAA) verwenden:Mit RWS ist ein eingeschränkter websiteübergreifender Cookie-Zugriff zwischen einer kleinen Gruppe ähnlicher Domains möglich. Bei RWS ist keine Aufforderung des Nutzers erforderlich, wenn der Speicherzugriff mit der Storage Access API angefordert wird. Dies ermöglicht die SSO für RPs, die sich im selben RWS wie der IdP befinden. RWS unterstützt jedoch nur den websiteübergreifenden Cookie-Zugriff für eine begrenzte Anzahl von Domains.
• Web Authentication API verwenden: Mit der Web Authentication API können vertrauende Seiten (Relying Parties, RPs) eine begrenzte Anzahl von verknüpften Ursprüngen registrieren, über die Anmeldedaten erstellt und verwendet werden können.
• Wenn Sie Nutzer in mehr als fünf verknüpften Domains authentifizieren, sollten Sie sich Federated Credential Management (FedCM) ansehen: Mit FedCM können Identitätsanbieter Chrome für die Verarbeitung von identitätsbezogenen Abläufen verwenden, ohne dass Drittanbieter-Cookies erforderlich sind. In Ihrem Fall könnte Ihre „Anmeldedomain“ als FedCM-Identitätsanbieter fungieren und zur Authentifizierung von Nutzern in Ihren anderen Domains verwendet werden.

Authentifizierung über Einbettungen

Angenommen, ein 3-party-app.example-iFrame ist in top-level.example eingebettet. Auf 3-party-app.example kann sich der Nutzer entweder mit 3-party-app.example-Anmeldedaten oder mit einem anderen Drittanbieter anmelden.

Der Nutzer klickt auf „Anmelden“ und authentifiziert sich im 3-party-app.examplePop-up. Über das Pop-up von 3-party-app.example wird ein eigenes Cookie gesetzt. Der in top-level.example eingebettete 3-party-app.example-Frame ist jedoch partitioniert und kann nicht auf das Cookie zugreifen, das im Kontext mit selbst erhobenen Daten auf der 3-party-app.example gesetzt wurde.

Das gleiche Problem tritt auf, wenn ein Nutzer von top-level.example zu 3-party-app.example und zurück weitergeleitet wird. Das Cookie wird im Kontext der eigenen Website von 3-party-app.example geschrieben, aber es ist partitioniert und nicht innerhalb des 3-party-app.example-Iframes zugänglich.

Wenn der Nutzer den eingebetteten Ursprung in einem übergeordneten Kontext besucht hat, ist die Storage Access API eine gute Lösung.

Um von Lösungen zu migrieren, die auf Drittanbieter-Cookies basieren, empfehlen wir den Identitätsanbietern, die FedCM API zu verwenden und FedCM nicht über Pop-ups, sondern über eingebettete Inhalte aufzurufen.

Eine weitere vorgeschlagene Lösung für diesen Ablauf, partitionierte Pop-ups, wird derzeit implementiert.

Anmeldung über soziale Netzwerke

Anmeldeschaltflächen wie Über Google anmelden, Über Facebook anmelden und Über Twitter anmelden sind ein eindeutiges Zeichen dafür, dass auf Ihrer Website ein Anbieter für föderierte Identitäten verwendet wird. Jeder Anbieter von föderierten Identitäten hat seine eigene Implementierung.

Wenn Sie die eingestellte Google Sign-In JavaScript-Plattformbibliothek verwenden, finden Sie hier Informationen zur Migration zur neueren Google Identity Services-Bibliothek für Authentifizierung und Autorisierung.

Die meisten Websites, die die neuere Google Identity Services-Bibliothek verwenden, sind nicht mehr auf Drittanbieter-Cookies angewiesen, da die Bibliothek automatisch auf die Verwendung von FedCM umgestellt wird, um für Kompatibilität zu sorgen. Wir empfehlen, Ihre Website zu testen, wenn das Testflag für die Einstellung von Drittanbieter-Cookies aktiviert ist, und bei Bedarf die Checkliste für die FedCM-Migration zur Vorbereitung zu verwenden.

Auf Nutzerdaten aus eingebetteten Inhalten zugreifen und sie ändern

Eingebettete Inhalte werden häufig für User Journeys verwendet, z. B. für den Zugriff auf oder die Verwaltung von Nutzerprofilen oder Abodaten.

Ein Nutzer könnte sich beispielsweise bei website.example anmelden, in das ein subscriptions.example-Widget eingebettet ist. Über dieses Widget können Nutzer ihre Daten verwalten, z. B. Premiuminhalte abonnieren oder Zahlungsinformationen aktualisieren. Um Nutzerdaten zu ändern, muss das eingebettete Widget möglicherweise auf seine eigenen Cookies zugreifen, während es in website.example eingebettet ist. Wenn diese Daten auf website.example beschränkt werden sollen, kann CHIPS dafür sorgen, dass das eingebettete Element auf die erforderlichen Informationen zugreifen kann. Mit CHIPS hat ein subscriptions.example-Widget, das auf website.example eingebettet ist, keinen Zugriff auf die Abodaten des Nutzers auf anderen Websites.

Ein weiterer Fall: Ein Video von streaming.example ist in website.example eingebettet und der Nutzer hat ein Premium-Abo von streaming.example. Das Widget muss darüber informiert werden, um Anzeigen zu deaktivieren. Wenn auf dasselbe Cookie auf mehreren Websites zugegriffen werden muss, können Sie die Storage Access API verwenden, wenn der Nutzer streaming.example bereits auf oberster Ebene besucht hat, und die Related Website Sets, wenn streaming.example zum Set der website.example gehört.

Ab Chrome 131 ist FedCM in die Storage Access API integriert. Wenn der Nutzer die FedCM-Aufforderung akzeptiert, gewährt der Browser dem Identitätsanbieter den Zugriff auf nicht partitionierten Speicher.

Weitere Informationen dazu, welche API du für die Verarbeitung einer bestimmten User Journey mit eingebetteten Inhalten verwenden solltest, findest du im Leitfaden für Einbettungen.

Andere User Journeys

Nutzerinteraktionen, die nicht auf Drittanbieter-Cookies basieren, sollten von Änderungen bei der Handhabung von Drittanbieter-Cookies in Chrome nicht betroffen sein. Die vorhandenen Lösungen wie Anmeldung, Abmeldung oder Kontowiederherstellung im Kontext von selbst erhobenen Daten und die Bestätigung in zwei Schritten sollten wie vorgesehen funktionieren. Potenzielle Bruchstellen wurden bereits beschrieben. Weitere Informationen zu einer bestimmten API finden Sie auf der API-Statusseite. Melden Sie alle Probleme unter goo.gle/report-3pc-broken. Sie können auch ein Feedbackformular senden oder ein Problem auf GitHub im Repository für den Privacy Sandbox-Entwicklersupport melden.

Website analysieren

Wenn auf Ihrer Website einer der in diesem Leitfaden beschriebenen User Journeys implementiert ist, müssen Sie Ihre Website entsprechend vorbereiten: Prüfen Sie, ob Ihre Website Drittanbieter-Cookies verwendet, testen Sie, ob sie funktioniert, und stellen Sie auf die empfohlenen Lösungen um.