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

Drittanbieter-Cookies können durch Browsereinschränkungen, Nutzereinstellungen, Entwickler-Flags oder Unternehmensrichtlinien blockiert werden.

Ihre Website oder Ihr Dienst muss allen Nutzern eine hervorragende Erfahrung bieten, unabhängig davon, ob Drittanbieter-Cookies verfügbar sind.

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

Wenn auf Ihrer Website nur Abläufe innerhalb derselben Domain und Subdomains wie publisher.example und login.publisher.example verarbeitet werden, werden keine websiteübergreifenden Cookies verwendet. Ihr Anmeldeablauf sollte daher 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 Sign-in oder Facebook Login, oder wenn die Nutzerauthentifizierung auf Ihrer Website über mehrere Domains oder Subdomains hinweg geteilt werden muss, müssen Sie möglicherweise Änderungen an Ihrer Website vornehmen, um einen reibungslosen Übergang weg von websiteübergreifenden Cookies zu gewährleisten.

Häufige Kaufprozesse

Bisher waren für viele Identitäts-Workflows Drittanbieter-Cookies erforderlich. In der Tabelle sind einige häufige Nutzerpfade und potenzielle Lösungen für jeden dieser Pfade aufgeführt, die nicht von Drittanbieter-Cookies abhängen. In den folgenden Abschnitten wird die Begründung für diese Empfehlungen erläutert.

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

Die mit diesem Symbol science gekennzeichneten APIs

in der Tabelle befinden sich in einem frühen Entwicklungsstadium. Ihr Feedback ist wertvoll und wird ihnen helfen, sich weiterzuentwickeln. Teilen Sie uns Ihre Meinung zu diesen APIs mit: Partitioned Popins.

Nutzerpfad	Empfohlene APIs
Anmeldung über soziale Netzwerke	Für Identitätsanbieter: FedCM implementieren Für vertrauende Parteien: Identitätsanbieter kontaktieren
Einmalanmeldung (SSO)	Für Identitätsanbieter oder benutzerdefinierte Lösungen: Gruppen ähnlicher Websites
Verwaltung von Nutzerprofilen	Storage Access API Related Website Sets CHIPS FedCM + SAA
Aboverwaltung	Storage Access API Related Website Sets CHIPS FedCM + SAA
Authentifizierung	Storage Access API FedCM Web Authentication API sciencePartitioned Popins
Andere User Journeys	Diese Szenarien sind in der Regel nicht von Drittanbieter-Cookies abhängig und sollten daher nicht betroffen sein.

Identitätsbezogene Nutzeraktionen testen

Am besten testen Sie, ob Ihr Anmeldevorgang von Änderungen bei Drittanbieter-Cookies betroffen ist, indem Sie die Registrierung, die Passwortwiederherstellung, die Anmeldung und die Abmeldung mit aktiviertem Testflag für Drittanbieter-Cookies durchlaufen.

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

• Nutzerregistrierung:Das Erstellen eines neuen Kontos funktioniert wie erwartet. Wenn Sie Drittanbieter-Identitätsanbieter 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 Anmeldeworkflow funktioniert innerhalb derselben Domain und beim Aufrufen anderer Domains. Denken Sie daran, jede Anmeldeintegration zu testen.
• Abmeldung:Der Abmeldevorgang 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 weiterhin funktionieren, insbesondere wenn dabei websiteübergreifende Ressourcen geladen werden. Wenn Sie beispielsweise ein CDN zum Laden von Nutzerprofilbildern verwenden, prüfen Sie, ob dies weiterhin funktioniert. Wenn Sie kritische User Journeys wie die Kaufabwicklung haben, die nur nach der Anmeldung möglich sind, sollten Sie prüfen, ob diese weiterhin funktionieren.

Anmeldelösungen

In diesem Abschnitt finden Sie genauere Informationen dazu, wie sich die Änderungen auf diese Abläufe auswirken können.

Drittanbieter-Einmalanmeldung (SSO)

Die Drittanbieter-Einmalanmeldung (SSO) ermöglicht es einem Nutzer, sich mit einem einzigen Satz von Anmeldedaten auf einer Plattform zu authentifizieren und dann auf mehrere Anwendungen und Websites zuzugreifen, ohne seine Anmeldedaten noch einmal eingeben zu müssen. Aufgrund der Komplexität der Implementierung einer SSO-Lösung entscheiden sich viele Unternehmen für einen Drittanbieter, um den Anmeldestatus zwischen mehreren Ursprüngen zu teilen. 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 zu erfahren, wie sich Abhängigkeiten von Drittanbieter-Cookies auf die Lösung auswirken und welchen Ansatz er für seinen Dienst empfiehlt. Einige Anbieter stellen still und leise auf andere Technologien um. In diesem Fall müssen sich die vertrauenden Parteien nicht anpassen.

Mehrere Domains

Einige Websites verwenden eine andere Domain nur zur Authentifizierung von Nutzern, die nicht für Same-Site-Cookies infrage kommen. Ein Beispiel: Eine Website verwendet example.com für die Hauptwebsite und login.example für den Anmeldevorgang. Möglicherweise ist der Zugriff auf Drittanbieter-Cookies erforderlich, um sicherzustellen, dass der Nutzer in beiden Domains authentifiziert wird.

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

Mögliche Migrationspfade für dieses Szenario:

• Aktualisierung zur Verwendung von Erstanbieter-Cookies („SameSite“):Die Websiteinfrastruktur wird so geändert, dass der Anmeldevorgang in derselben Domain (oder einer Subdomain) wie die Hauptwebsite gehostet wird. Dabei werden nur Erstanbieter-Cookies verwendet. Je nach Einrichtung der Infrastruktur kann dies mit einem höheren Aufwand verbunden sein.
• Gruppen ähnlicher Websites (Related Website Sets, RWS) und Storage Access API (SAA) verwenden:RWS ermöglichen einen eingeschränkten websiteübergreifenden Cookie-Zugriff zwischen einer kleinen Gruppe ähnlicher Domains. Mit RWS ist keine Nutzeraufforderung erforderlich, wenn Speicherzugriff mit der Storage Access API angefordert wird. So ist die Einmalanmeldung für diese RPs möglich, wenn sie sich im selben RWS wie der Identitätsanbieter befinden. RWS unterstützt jedoch nur für eine begrenzte Anzahl von Domains den Zugriff auf Website-übergreifende Cookies.
• Web Authentication API verwenden:Die Web Authentication API ermöglicht es vertrauenden Seiten (Relying Parties, RPs), eine begrenzte Anzahl von zugehörigen Ursprüngen zu registrieren, für die Anmeldedaten erstellt und verwendet werden können.
• Wenn Sie Nutzer über mehr als fünf verknüpfte Domains hinweg authentifizieren, sollten Sie Federated Credential Management (FedCM) in Betracht ziehen:Mit FedCM können Identitätsanbieter sich darauf verlassen, dass Chrome identitätsbezogene Abläufe ohne Drittanbieter-Cookies verarbeitet. 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 auf 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.example-Pop-up. Mit dem Pop-up 3-party-app.example wird ein eigenes Cookie gesetzt. Der auf top-level.example eingebettete 3-party-app.example-iFrame ist jedoch partitioniert und kann nicht auf das Cookie zugreifen, das im Erstanbieterkontext auf der 3-party-app.example festgelegt wurde.

Dasselbe Problem würde auftreten, 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 3-party-app.example geschrieben, ist aber partitioniert und nicht im 3-party-app.example-iFrame zugänglich.

Wenn der Nutzer den eingebetteten Ursprung im Kontext der obersten Ebene besucht hat, ist die Storage Access API eine gute Lösung.

Um von Lösungen wegzukommen, die auf Drittanbieter-Cookies basieren, empfehlen wir Identitätsanbietern, die FedCM API zu verwenden und FedCM aus Einbettungen statt aus Pop-ups aufzurufen.

Eine weitere vorgeschlagene Lösung für diesen Ablauf, Partitioned Popins, wird derzeit implementiert.

Anmeldung über soziale Netzwerke

Anmeldeschaltflächen wie Mit Google anmelden, Facebook-Login und Mit Twitter anmelden sind ein deutliches Zeichen dafür, dass auf Ihrer Website ein Anbieter für föderierte Identitäten verwendet wird. Jeder Anbieter von Verbundidentitäten hat seine eigene Implementierung.

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

Die meisten Websites, die die neuere Google Identity Services-Bibliothek verwenden, sind nicht mehr auf Drittanbieter-Cookies angewiesen, da die Bibliothek im Hintergrund zur Kompatibilität auf FedCM umgestellt wird. Wir empfehlen, Ihre Website mit aktiviertem Testflag für die Einstellung von Drittanbieter-Cookies zu testen und sich bei Bedarf mit der FedCM-Migrations-Checkliste vorzubereiten.

Auf Nutzerdaten in Einbettungen zugreifen und diese ändern

Eingebettete Inhalte werden häufig für Nutzeraktionen wie den Zugriff auf oder die Verwaltung von Nutzerprofil- oder Abodaten verwendet.

Ein Nutzer meldet sich beispielsweise bei website.example an, in das ein subscriptions.example-Widget eingebettet ist. Mit diesem Widget können Nutzer ihre Daten verwalten, z. B. Premium-Inhalte abonnieren oder Abrechnungsinformationen aktualisieren. Zum Ändern von Nutzerdaten muss das eingebettete Widget möglicherweise auf seine eigenen Cookies zugreifen, während es auf website.example eingebettet ist. Wenn diese Daten auf website.example beschränkt werden sollen, können CHIPS dafür sorgen, dass das eingebettete Element auf die benötigten Informationen zugreifen kann. Mit CHIPS hat das subscriptions.example-Widget, das auf website.example eingebettet ist, keinen Zugriff auf die Abo-Daten des Nutzers auf anderen Websites.

Ein anderes Beispiel: Ein Video von streaming.example ist auf 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, sollten Sie die Storage Access API verwenden, wenn der Nutzer streaming.example zuvor als Website der obersten Ebene besucht hat, und Gruppen ähnlicher Websites, wenn die Gruppe von website.example die streaming.example enthält.

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

Weitere Informationen dazu, welche API für einen bestimmten Nutzerpfad mit eingebetteten Inhalten verwendet werden sollte, finden Sie im Leitfaden für Einbettungen.

Andere User Journeys

Nutzeraktionen, die nicht auf Drittanbieter-Cookies basieren, sollten nicht von Änderungen bei der Handhabung von Drittanbieter-Cookies in Chrome betroffen sein. Die bestehenden Lösungen wie Anmelden, Abmelden oder Kontowiederherstellung im Erstanbieterkontext sowie die 2‑Faktor-Authentifizierung sollten wie vorgesehen funktionieren. Mögliche Bruchstellen wurden bereits beschrieben. Weitere Informationen zu einer bestimmten API finden Sie auf der Seite API-Status.

Website prüfen

Wenn auf Ihrer Website einer der in diesem Leitfaden beschriebenen Nutzerpfade implementiert ist, müssen Sie dafür sorgen, dass Ihre Websites vorbereitet sind: Prüfen Sie, wofür Ihre Website Drittanbieter-Cookies nutzt, testen Sie, ob es zu Problemen kommt, und stellen Sie auf die empfohlenen Lösungen um.