Best Practices für die Verwendung von signInWithRedirect in Browsern, die den Zugriff auf Speicher von Drittanbietern blockieren

In diesem Dokument werden die Best Practices für die Verwendung von Weiterleitungsanmeldungen in Browsern beschrieben, die Drittanbieter-Cookies blockieren. Sie müssen eine der hier aufgeführten Optionen befolgen, damit signInWithRedirect() in Produktionsumgebungen in allen Browsern wie vorgesehen funktioniert.

Hinweis: Ab dem 24. Juni 2024 ist die Implementierung einer der Optionen erforderlich, damit die Anmeldung über eine Weiterleitung in Google Chrome ab M115 funktioniert. Dies ist bereits für Firefox ab Version 109 und Safari ab Version 16.1 erforderlich.

Übersicht

Damit der signInWithRedirect()-Ablauf für Sie und Ihre Nutzer nahtlos funktioniert, verwendet das Firebase Authentication JavaScript SDK einen ursprungsübergreifenden iFrame, der eine Verbindung zur Firebase Hosting-Domain Ihrer App herstellt. Dieser Mechanismus funktioniert jedoch nicht mit Browsern, die den Zugriff auf Speicher von Drittanbietern blockieren.

Da es selten eine Option ist, Nutzer zu bitten, die Speicherpartitionierung im Browser zu deaktivieren, sollten Sie stattdessen je nach den Besonderheiten Ihres Anwendungsfalls eine der folgenden Einrichtungsoptionen auf Ihre App anwenden.

• Wenn Sie Ihre App mit Firebase Hosting auf einer Subdomain von firebaseapp.com hosten, sind Sie von diesem Problem nicht betroffen und müssen nichts weiter tun.
• Wenn Sie Ihre App mit Firebase Hosting auf einer benutzerdefinierten Domain oder einer Subdomain von web.app hosten, verwenden Sie Option 1.
• Wenn Sie Ihre App mit einem anderen Dienst als Firebase hosten, verwenden Sie Option 2, Option 3, Option 4 oder Option 5.

Option 1: Firebase-Konfiguration aktualisieren, um Ihre benutzerdefinierte Domain als authDomain zu verwenden

Wenn Sie Ihre App mit Firebase Hosting über eine benutzerdefinierte Domain hosten, können Sie das Firebase SDK so konfigurieren, dass Ihre benutzerdefinierte Domain als authDomain verwendet wird. So wird sichergestellt, dass Ihre App und der Authentifizierungs-iFrame dieselbe Domain verwenden, was das Anmeldeproblem verhindert. Wenn Sie Firebase Hosting nicht verwenden, müssen Sie eine andere Option verwenden. Achten Sie darauf, dass Sie die benutzerdefinierte Domain in demselben Projekt eingerichtet haben, das Sie für die Authentifizierung verwenden.

So aktualisieren Sie Ihre Firebase-Konfiguration, um Ihre benutzerdefinierte Domain als Authentifizierungsdomain zu verwenden:

1. Konfigurieren Sie das Firebase JS SDK so, dass Ihre benutzerdefinierte Domain als authDomain verwendet wird:

   const firebaseConfig = {
     apiKey: "<api-key>",
     authDomain: "<the-domain-that-serves-your-app>",
     databaseURL: "<database-url>",
     projectId: "<project-id>",
     appId: "<app-id>"
   };
   

Wichtig: Normalerweise sollten Sie keine anderen Felder im Firebase-Konfigurationsobjekt ändern. Weitere Informationen zum Firebase-Konfigurationsobjekt

1. Fügen Sie die neue authDomain der Liste der autorisierten Weiterleitungs-URIs Ihres OAuth-Anbieters hinzu. Wie Sie das tun, hängt vom Anbieter ab. Im Allgemeinen können Sie jedoch den Abschnitt „Vorbereitung“ bei jedem Anbieter aufrufen, um eine genaue Anleitung zu erhalten (z. B. beim Facebook-Anbieter). Der aktualisierte URI für die Autorisierung sieht so aus: https://<the-domain-that-serves-your-app>/__/auth/handler. Das abschließende /__/auth/handler ist wichtig.

   Wenn Sie einen SAML-Anbieter verwenden, fügen Sie die neue authDomain der SAML-ACS-URL (Assertion Consumer Service) hinzu.

2. Ihre continue_uri muss in der Liste der autorisierten Domains enthalten sein.

3. Stellen Sie die App bei Bedarf noch einmal mit Firebase Hosting bereit, um die aktuelle Firebase-Konfigurationsdatei abzurufen, die unter /__/firebase/init.json gehostet wird.

Option 2: Zu signInWithPopup() wechseln

Verwenden Sie signInWithPopup() anstelle von signInWithRedirect(). Der restliche Code Ihrer App bleibt unverändert, aber das UserCredential-Objekt wird anders abgerufen.

Webversion 9

  // Before
  // ==============
  signInWithRedirect(auth, new GoogleAuthProvider());
  // After the page redirects back
  const userCred = await getRedirectResult(auth);

  // After
  // ==============
  const userCred = await signInWithPopup(auth, new GoogleAuthProvider());

Webversion 8

  // Before
  // ==============
  firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());
  // After the page redirects back
  var userCred = await firebase.auth().getRedirectResult();

  // After
  // ==============
  var userCred = await firebase.auth().signInWithPopup(
      new firebase.auth.GoogleAuthProvider());
```

Die Anmeldung über ein Pop-up ist für Nutzer nicht immer ideal. Pop-ups werden gelegentlich vom Gerät oder der Plattform blockiert und der Ablauf ist für mobile Nutzer weniger reibungslos. Wenn die Verwendung von Pop-ups für Ihre App ein Problem darstellt, müssen Sie eine der anderen Optionen verwenden.

Option 3: Authentifizierungsanfragen an firebaseapp.com weiterleiten

Der signInWithRedirect-Ablauf beginnt mit der Weiterleitung von Ihrer App-Domain zu der Domain, die im Parameter authDomain in der Firebase-Konfiguration angegeben ist (standardmäßig „.firebaseapp.com“). authDomain hostet den Code für die Anmeldehilfe, der zum Identitätsanbieter weiterleitet. Bei erfolgreicher Anmeldung wird der Nutzer zurück zur App-Domain weitergeleitet.

Wenn der Authentifizierungsablauf zu Ihrer App-Domain zurückkehrt, wird auf den Browserspeicher der Domain des Anmeldeassistenten zugegriffen. Mit dieser Option und der folgenden Option (zum Selbsthosten des Codes) wird der ursprungsübergreifende Speicherzugriff eliminiert, der sonst von Browsern blockiert wird.

1. Richten Sie auf Ihrem Anwendungsserver einen Reverse-Proxy ein, damit GET-/POST-Anfragen an https://<app domain>/__/auth/ an https://<project>.firebaseapp.com/__/auth/ weitergeleitet werden. Diese Weiterleitung muss für den Browser transparent sein. Dies ist nicht über eine 302-Weiterleitung möglich.

   Wenn Sie nginx verwenden, um Ihre benutzerdefinierte Domain bereitzustellen, sieht die Reverse-Proxy-Konfiguration so aus:

   # reverse proxy for signin-helpers for popup/redirect sign in.
   location /__/auth {
     proxy_pass https://<project>.firebaseapp.com;
   }
   

2. Folgen Sie der Anleitung unter Option 1, um die autorisierte redirect_uri, die ACS-URL und die authDomain zu aktualisieren. Nachdem Sie Ihre App noch einmal bereitgestellt haben, sollte der ursprungsübergreifende Speicherzugriff nicht mehr erfolgen.

Option 4: Code für die Anmeldehilfe in Ihrer Domain selbst hosten

Eine weitere Möglichkeit, den ursprungsübergreifenden Speicherzugriff zu vermeiden, besteht darin, den Firebase-Anmeldehilfecode selbst zu hosten. Dieser Ansatz funktioniert jedoch nicht für die Anmeldung mit Apple oder SAML. Verwenden Sie diese Option nur, wenn die Einrichtung des Reverse-Proxys in Option 3 nicht möglich ist.

Das Hosten des Hilfscodes umfasst die folgenden Schritte:

1. Laden Sie die zu hostenden Dateien mit den folgenden Befehlen aus dem Verzeichnis <project>.firebaseapp.com herunter:

   mkdir signin_helpers/ && cd signin_helpers
   wget https://<project>.firebaseapp.com/__/auth/handler
   wget https://<project>.firebaseapp.com/__/auth/handler.js
   wget https://<project>.firebaseapp.com/__/auth/experiments.js
   wget https://<project>.firebaseapp.com/__/auth/iframe
   wget https://<project>.firebaseapp.com/__/auth/iframe.js
   wget https://<project>.firebaseapp.com/__/auth/links
   wget https://<project>.firebaseapp.com/__/auth/links.js
   wget https://<project>.firebaseapp.com/__/firebase/init.json
   

2. Hosten Sie die oben genannten Dateien unter Ihrer App-Domain. Achten Sie darauf, dass Ihr Webserver auf https://<app domain>/__/auth/<filename> und https://<app domain>/__/firebase/init.json reagieren kann.

   Hier finden Sie eine Beispiel-Serverimplementierung, mit der die Dateien heruntergeladen und gehostet werden.

3. Folgen Sie der Anleitung unter Option 1, um die autorisierten redirect_uri und Ihre authDomain zu aktualisieren. Nachdem Sie Ihre App noch einmal bereitgestellt haben, sollte der ursprungsübergreifende Speicherzugriff nicht mehr erfolgen.

Wichtig: Wenn Sie diese Option verwenden, müssen Sie die Dateien regelmäßig herunterladen und synchronisieren, damit die neuesten Fehlerkorrekturen und Funktionen übernommen werden. Insbesondere im 3. Quartal 2026 wurden mehrere wichtige Fehlerkorrekturen veröffentlicht. Wenn Sie Ihre gehosteten Dateien seitdem nicht synchronisiert haben, sollten Sie dies tun.

Option 5: Anmeldung beim Anbieter unabhängig verwalten

Wichtig: Dies ist ein komplexer Ansatz, bei dem zusätzliche SDKs verwendet werden und der für SAML-Anbieter sehr aufwendig sein kann.

Das Firebase Authentication SDK bietet signInWithPopup() und signInWithRedirect() als praktische Methoden, um komplizierte Logik zu verpacken und die Einbindung eines anderen SDKs zu vermeiden. Sie können beide Methoden vollständig vermeiden, indem Sie sich unabhängig bei Ihrem Anbieter anmelden und dann signInWithCredential() verwenden, um die Anmeldedaten des Anbieters gegen Firebase Authentication-Authentifizierungsdaten auszutauschen. Sie können beispielsweise das Google Sign-In SDK und den Beispielcode verwenden, um Google-Kontoanmeldedaten abzurufen, und dann mit dem folgenden Code neue Google-Anmeldedaten instanziieren:

Webversion 9

  // `googleUser` from the onsuccess Google Sign In callback.
  //  googUser = gapi.auth2.getAuthInstance().currentUser.get();
  const credential = GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);
  const result = await signInWithCredential(auth, credential);

Webversion 8

  // `googleUser` from the onsuccess Google Sign In callback.
  const credential = firebase.auth.GoogleAuthProvider.credential(
      googleUser.getAuthResponse().id_token);
  const result = await firebase.auth().signInWithCredential(credential);

Nachdem Sie signInWithCredential() aufgerufen haben, funktioniert der Rest Ihrer Anwendung wie zuvor.

Eine Anleitung zum Abrufen von Apple-Anmeldedaten finden Sie hier.