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 Google Log-in oder Facebook Log-in, 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 einen reibungslosen Übergang von websiteübergreifenden Cookies zu ermöglichen.
Häufige Kaufprozesse
Bisher beruhten viele Identitätsworkflows auf Drittanbieter-Cookies. In der Tabelle sind einige gängige User Journeys und mögliche Lösungen für diese aufgeführt, 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 häufige Anwendungsfälle
| Nutzererfahrung | Empfohlene APIs |
|---|---|
| Über soziale Netzwerke anmelden |
Für Identitätsanbieter: FedCM implementieren Für vertrauende Parteien: Wenden Sie sich an Ihren Identitätsanbieter |
| Abmeldung über den Front-Channel | Für Identitätsanbieter: FedCM implementieren |
|
Für Identitätsanbieter oder benutzerdefinierte Lösungen: Ähnliche Website-Sets |
|
| Nutzerprofile verwalten |
Storage Access API Gruppen ähnlicher Websites CHIPS FedCM |
|
Storage Access API Weitere Website-Sets CHIPS FedCM |
|
| Authentifizierung |
Storage Access API FedCM Web Authentication API sciencePartitionierte Popins |
| Bei diesen Szenarien sind in der Regel keine Drittanbieter-Cookies erforderlich. Daher sind keine Auswirkungen zu erwarten. |
Identitätsbezogene User Journeys testen
Am besten testen Sie, ob sich die Änderungen an Drittanbieter-Cookies auf den Anmeldevorgang 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 – über die Weboberfläche, über CAPTCHAs und den 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 Abläufe auswirken können.
Einmalanmeldung (SSO) von Drittanbietern
Mit der Einmalanmeldung (SSO) eines Drittanbieters können sich Nutzer mit denselben Anmeldedaten 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. Der beste Ansatz besteht darin, den Anbieter darüber zu informieren, wie sich die Abhängigkeiten von Drittanbieter-Cookies 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 Kunden nichts unternehmen.
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 wird.
Einige Unternehmen können mehrere Produkte anbieten, 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: RWS ermöglicht einen eingeschränkten websiteübergreifenden Cookie-Zugriff zwischen einer kleinen Gruppe ähnlicher Domains. Bei RWS ist keine Aufforderung für Nutzer erforderlich, wenn der Speicherzugriff mit der Storage Access API angefordert wird. Dies ermöglicht die SSO für RPs, die sich in derselben RWS wie der IdP befinden. RWS unterstützt jedoch nur den websiteübergreifenden Cookie-Zugriff über eine begrenzte Anzahl von Domains hinweg.
- 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 den Anmeldedaten eines anderen Drittanbieters anmelden.
Der Nutzer klickt auf „Anmelden“ und authentifiziert sich im Pop-up von 3-party-app.example. Ü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 der 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 Erstanbieterkontext der 3-party-app.example-Website geschrieben, aber partitioniert und innerhalb des 3-party-app.example-iFrames nicht 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. FedCM sollte dabei nicht über Pop-ups, sondern über eingebettete Inhalte aufgerufen werden.
Eine weitere vorgeschlagene Lösung für diesen Ablauf, partitionierte Popins, wird derzeit implementiert.
Anmeldung über soziale Netzwerke
Anmeldeschaltflächen wie Über Google anmelden, Facebook-Anmeldung und Über Twitter anmelden sind ein eindeutiges Zeichen dafür, dass auf Ihrer Website ein föderierter Identitätsanbieter verwendet wird. Jeder Anbieter föderierter Identitäten hat seine eigene Implementierung.
Wenn Sie die veraltete 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 aus Gründen der Kompatibilität automatisch zu FedCM migriert. Wir empfehlen, Ihre Website zu testen, wenn das Test-Flag für die Einstellung von Drittanbieter-Cookies aktiviert ist. Verwenden Sie bei Bedarf die Checkliste für die FedCM-Migration, um sich vorzubereiten.
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 Nutzerprofil- oder Abodaten.
Ein Nutzer kann sich beispielsweise bei website.example anmelden, in das ein subscriptions.example-Widget eingebettet ist. Mit diesem Widget können Nutzer ihre Daten verwalten, z. B. Premiuminhalte abonnieren oder Zahlungsinformationen aktualisieren. Zum Ändern von Nutzerdaten muss das eingebettete Widget möglicherweise auf seine eigenen Cookies zugreifen, während es in website.example eingebettet ist. In einem Szenario, in dem diese Daten nach website.example isoliert werden sollen, kann CHIPS dafür sorgen, dass die Einbettung auf die benötigten Informationen zugreifen kann. Mit CHIPS hat das in website.example eingebettete subscriptions.example-Widget 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 zuvor 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 bei dieser Integration die FedCM-Aufforderung annimmt, gewährt der Browser dem IdP-Einbettungszugriff auf nicht partitionierte Speicher.
Weitere Informationen dazu, welche API du für einen bestimmten Nutzerpfad mit eingebetteten Inhalten verwenden solltest, findest du im Leitfaden zu Einbettungen.
Front-Channel-Abmeldung
Die Abmeldung über den Front-Channel ist ein Mechanismus, mit dem sich ein Nutzer von allen zugehörigen Apps abmelden kann, wenn er sich bei einem Dienst abmeldet. Für das Front-Channel-Logout von OIDC muss der IdP mehrere Iframes der vertrauenden Partei (Relying Party, RP) einbetten, die auf den Cookies der RP basieren.
Wenn Ihre Lösung auf einem Identitätsanbieter basiert, sind möglicherweise kleinere Änderungen erforderlich, z. B. ein Bibliotheksupgrade. Weitere Informationen erhalten Sie von Ihrem Identitätsanbieter.
Um diesen Anwendungsfall zu lösen, hat FedCM mit der Funktion logoutRPs experimentiert. So konnte der Identitätsanbieter alle RPs abmelden, für die der Nutzer zuvor die Kommunikation zwischen RP und Identitätsanbieter genehmigt hatte. Diese Funktion ist nicht mehr verfügbar. Wir empfehlen Ihnen jedoch, sich den ursprünglichen Vorschlag anzusehen und uns Ihr Feedback mitzuteilen, wenn Sie an dieser Funktion interessiert sind oder sie benötigen.
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 bestehenden Lösungen wie Anmeldung, Abmeldung oder Kontowiederherstellung im eigenen Kontext (2FA) sollten wie vorgesehen funktionieren. Potenzielle Bruchstellen wurden bereits beschrieben. Weitere Informationen zu einer bestimmten API finden Sie auf der Statusseite der API. Melden Sie etwaige Probleme an goo.gle/report-3pc-broken. Sie können auch ein Feedbackformular einreichen oder ein Problem auf GitHub im Privacy Sandbox-Entwicklersupport-Repository melden.
Website analysieren
Wenn auf Ihrer Website eine der in diesem Leitfaden beschriebenen User Journeys implementiert ist, müssen Sie Ihre Websites vorbereiten: Prüfen Sie, wofür Ihre Website Drittanbieter-Cookies nutzt, testen Sie, ob es zu Unterbrechungen kommt, und stellen Sie auf die empfohlenen Lösungen um.