Best practice per l'utilizzo di signInWithRedirect sui browser che bloccano l'accesso allo spazio di archiviazione di terze parti

Questo documento descrive le best practice per l'utilizzo degli accessi con reindirizzamento sui browser che bloccano i cookie di terze parti. Devi seguire una delle opzioni elencate qui affinché signInWithRedirect() funzioni come previsto negli ambienti di produzione, in tutti i browser.

Nota: a partire dal 24 giugno 2024, l'implementazione di una delle opzioni sarà obbligatoria per il funzionamento del login con reindirizzamento su Google Chrome M115 e versioni successive. Questa funzionalità è già obbligatoria su Firefox 109 e versioni successive e Safari 16.1 e versioni successive.

Panoramica

Per rendere il flusso signInWithRedirect() fluido per te e i tuoi utenti, l'SDK JavaScript di Firebase Authentication utilizza un iframe multiorigine che si connette al dominio Firebase Hosting della tua app. Tuttavia, questo meccanismo non funziona con i browser che bloccano l'accesso allo spazio di archiviazione di terze parti.

Poiché chiedere agli utenti di disattivare le funzionalità di partizionamento dello spazio di archiviazione nel browser è raramente un'opzione, devi applicare una delle seguenti opzioni di configurazione alla tua app, a seconda delle specifiche del tuo caso d'uso.

• Se ospiti la tua app con Firebase Hosting su un sottodominio di firebaseapp.com, questo problema non ti riguarda e non è richiesta alcuna azione.
• Se ospiti la tua app con Firebase Hosting su un dominio personalizzato o un sottodominio di web.app, utilizza l'Opzione 1.
• Se l'hosting della tua app viene eseguito con un servizio diverso da Firebase, utilizza l'Opzione 2, l'Opzione 3, l'Opzione 4 o l'Opzione 5.

Opzione 1: aggiorna la configurazione di Firebase per utilizzare il tuo dominio personalizzato come authDomain

Se ospiti la tua app con Firebase Hosting utilizzando un dominio personalizzato, puoi configurare l'SDK Firebase in modo che utilizzi il tuo dominio personalizzato come authDomain. In questo modo, l'app e l'iframe di autenticazione utilizzano lo stesso dominio, evitando il problema di accesso. Se non utilizzi Firebase Hosting, devi utilizzare un'opzione diversa. Assicurati di aver configurato il dominio personalizzato nello stesso progetto che utilizzi per l'autenticazione.

Per aggiornare la configurazione di Firebase in modo da utilizzare il tuo dominio personalizzato come dominio di autenticazione, segui questi passaggi:

1. Configura l'SDK Firebase JS in modo che utilizzi il tuo dominio personalizzato come authDomain:

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

Importante: in genere, non devi modificare nessun altro campo nell'oggetto di configurazione di Firebase. Scopri di più sull'oggetto di configurazione Firebase.

1. Aggiungi il nuovo authDomain all'elenco degli URI di reindirizzamento autorizzati del tuo provider OAuth. La procedura dipende dal provider, ma in generale puoi seguire la sezione "Prima di iniziare" di qualsiasi provider per istruzioni precise (ad esempio, il provider Facebook). L'URI aggiornato da autorizzare è simile a https://<the-domain-that-serves-your-app>/__/auth/handler. Il carattere /__/auth/handler finale è importante.

   Analogamente, se utilizzi un provider SAML, aggiungi il nuovo authDomain all'URL ACS (Assertion Consumer Service) SAML.

2. Assicurati che il tuo continue_uri sia nell'elenco dei domini autorizzati.

3. Se necessario, esegui nuovamente il deployment con Firebase Hosting per recuperare il file di configurazione Firebase più aggiornato ospitato all'indirizzo /__/firebase/init.json.

Opzione 2: passa a signInWithPopup()

Utilizza signInWithPopup() anziché signInWithRedirect(). Il resto del codice dell'app rimane invariato, ma l'oggetto UserCredential viene recuperato in modo diverso.

Web version 9

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

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

Web version 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());
```

L'accesso tramite popup non è sempre l'ideale per gli utenti: i popup vengono occasionalmente bloccati dal dispositivo o dalla piattaforma e il flusso è meno fluido per gli utenti di dispositivi mobili. Se l'utilizzo dei popup è un problema per la tua app, dovrai seguire una delle altre opzioni.

Opzione 3: invia richieste di autenticazione proxy a firebaseapp.com

Il flusso signInWithRedirect inizia con il reindirizzamento dal dominio della tua app al dominio specificato nel parametro authDomain nella configurazione di Firebase (".firebaseapp.com" per impostazione predefinita). authDomain ospita il codice di supporto per l'accesso che reindirizza al provider di identità, che, in caso di esito positivo, reindirizza nuovamente al dominio dell'app.

Quando il flusso di autenticazione torna al dominio dell'app, viene eseguito l'accesso allo spazio di archiviazione del browser del dominio dell'assistente per l'accesso. Questa opzione e la successiva (per l'hosting autonomo del codice) eliminano l'accesso allo spazio di archiviazione multiorigine, che altrimenti viene bloccato dai browser.

1. Configura un reverse proxy sul server dell'app in modo che le richieste GET/POST a https://<app domain>/__/auth/ vengano inoltrate a https://<project>.firebaseapp.com/__/auth/. Assicurati che questo inoltro sia trasparente per il browser; non è possibile farlo tramite un reindirizzamento 302.

   Se utilizzi nginx per gestire il tuo dominio personalizzato, la configurazione del reverse proxy sarà simile alla seguente:

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

2. Segui i passaggi descritti nell'Opzione 1 per aggiornare l'redirect_uri autorizzato, l'URL ACS e il tuo authDomain. Una volta eseguito nuovamente il deployment dell'app, l'accesso allo spazio di archiviazione multiorigine non dovrebbe più verificarsi.

Opzione 4: ospita autonomamente il codice dell'assistente per l'accesso nel tuo dominio

Un altro modo per eliminare l'accesso allo spazio di archiviazione multiorigine è l'hosting autonomo del codice di supporto per l'accesso a Firebase. Tuttavia, questo approccio non funziona per l'accesso Apple o SAML. Utilizza questa opzione solo se la configurazione del reverse proxy nell'opzione 3 non è fattibile.

L'hosting del codice helper prevede i seguenti passaggi:

1. Scarica i file da ospitare dalla posizione <project>.firebaseapp.com eseguendo i seguenti comandi:

   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. Ospita i file sopra indicati nel dominio della tua app. Assicurati che il tuo server web possa rispondere a https://<app domain>/__/auth/<filename> e https://<app domain>/__/firebase/init.json.

   Ecco un esempio di implementazione del server che scarica e ospita i file.

3. Segui i passaggi descritti nell'Opzione 1 per aggiornare l'elenco redirect_uri autorizzati e il tuo authDomain. Una volta eseguito nuovamente il deployment dell'app, l'accesso allo spazio di archiviazione multiorigine non dovrebbe più verificarsi.

Importante: se utilizzi questa opzione, è importante scaricare e sincronizzare periodicamente i file per assicurarti che vengano applicate le correzioni di bug e le funzionalità più recenti. In particolare, nel terzo trimestre del 2026 sono state implementate diverse correzioni importanti. Se non hai sincronizzato i file ospitati da allora, dovresti farlo.

Opzione 5: gestisci l'accesso del provider in modo indipendente

Importante: questo è un approccio complesso che utilizza SDK aggiuntivi e potenzialmente può essere molto complicato per i provider SAML.

L'SDK Firebase Authentication fornisce signInWithPopup() e signInWithRedirect() come metodi pratici per racchiudere una logica complessa ed evitare la necessità di coinvolgere un altro SDK. Puoi evitare di utilizzare entrambi i metodi accedendo in modo indipendente al tuo provider, quindi utilizzando signInWithCredential() per scambiare le credenziali del provider con una credenziale di Firebase Authentication. Ad esempio, puoi utilizzare l'SDK Accedi con Google, il codice campione per ottenere una credenziale dell'Account Google, quindi creare un'istanza di una nuova credenziale Google eseguendo il seguente codice:

Web version 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);

Web version 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);

Dopo aver chiamato signInWithCredential(), il resto dell'app funziona come prima.

Le istruzioni per ottenere una credenziale Apple sono disponibili qui.