Chrome propone una nuova esperienza di scelta dell'utente con i cookie di terze parti. Devi preparare il tuo sito per gli utenti che scelgono di navigare senza cookie di terze parti.
In questa pagina troverai informazioni sugli scenari di identità più propensi a essere interessati, nonché riferimenti a possibili soluzioni.
Se il tuo sito web gestisce solo i flussi all'interno dello stesso dominio e degli stessi sottodomini, ad esempio publisher.example e login.publisher.example, non utilizzerà cookie tra siti e non è previsto che il flusso di accesso sia interessato dalle modifiche ai cookie di terze parti.
Tuttavia, se il tuo sito utilizza un dominio separato per l'accesso, ad esempio con Accedi con Google o Accedi con Facebook, o se il tuo sito deve condividere l'autenticazione utente su più domini o sottodomini, è possibile che tu debba apportare modifiche al sito per garantire una transizione senza problemi dai cookie cross-site.
Percorsi dell'utente comuni
In passato, molti flussi di lavoro relativi alle identità si basavano su cookie di terze parti. La tabella elenca alcuni percorsi utente comuni e potenziali soluzioni per ciascuno di questi che non dipendono dai cookie di terze parti. Le sezioni seguenti spiegano il ragionamento alla base di questi consigli.
API alternative consigliate per casi d'uso comuni
| Percorso dell'utente | API consigliate |
|---|---|
| Accesso tramite i social |
Per i provider di identità: implementa FedCM Per le parti attendibili: contatta il tuo provider di identità |
| Uscire dal canale principale | Per i provider di identità: implementa FedCM |
|
Per i provider di identità o le soluzioni personalizzate: Set di siti web correlati |
|
| Gestione dei profili utente |
API Accesso allo spazio di archiviazione Set di siti web correlati CHIPS FedCM |
|
API Accesso allo spazio di archiviazione Set di siti web correlati CHIPS FedCM |
|
| Autenticazione |
API Storage Access FedCM API Web Authentication sciencePopin partizionate |
| In genere, questi scenari non hanno dipendenze dai cookie di terze parti e non dovrebbero essere interessati. |
Testare i percorsi degli utenti relativi all'identità
Il modo migliore per verificare se il flusso di accesso è interessato dalle modifiche ai cookie di terze parti è eseguire i flussi di registrazione, recupero della password, accesso e uscita con il flag di test dei cookie di terze parti abilitato.
Ecco un elenco di controllo di ciò che devi verificare dopo aver limitato i cookie di terze parti:
- Registrazione utente: la creazione di un nuovo account funziona come previsto. Se utilizzi provider di identità di terze parti, verifica che la registrazione dei nuovi account funzioni per ogni integrazione.
- Recupero password: il recupero della password funziona come previsto, dall'interfaccia utente web, ai CAPTCHA, alla ricezione dell'email di recupero della password.
- Accesso: il flusso di lavoro di accesso funziona all'interno dello stesso dominio e quando si passa ad altri domini. Ricordati di testare ogni integrazione di accesso.
- Disconnessione: la procedura di disconnessione funziona come previsto e l'utente rimane disconnesso al termine del flusso di disconnessione.
Devi anche verificare che le altre funzionalità del sito che richiedono l'accesso dell'utente rimangano operative senza i cookie cross-site, in particolare se comportano il caricamento di risorse cross-site. Ad esempio, se utilizzi una CDN per caricare le immagini del profilo dell'utente, assicurati che funzioni ancora. Se hai percorsi utente critici, come il pagamento, che richiedono l'accesso, assicurati che continuino a funzionare.
Soluzioni di accesso
In questa sezione troverai informazioni più specifiche su come questi flussi potrebbero essere interessati.
Single Sign-On (SSO) di terze parti
Il Single Sign-On (SSO) di terze parti consente a un utente di autenticarsi con un unico set di credenziali su una piattaforma, quindi di accedere a più applicazioni e siti web senza dover reinserire i dati di accesso. A causa della complessità dell'implementazione di una soluzione SSO, molte aziende attivano l'utilizzo di un fornitore di soluzioni di terze parti per condividere lo stato di accesso tra più origini. Alcuni esempi di fornitori sono Okta, Ping Identity, Google Cloud IAM o Microsoft Entra ID.
Se la tua soluzione si basa su un fornitore di terze parti, è possibile che siano necessarie alcune modifiche minori, ad esempio un upgrade della libreria. L'approccio migliore è chiedere al fornitore indicazioni su come le dipendenze dai cookie di terze parti influiscono sulla soluzione e su quale approccio consiglia per il proprio servizio. Alcuni fornitori eseguiranno la migrazione in silenzio dai cookie di terze parti, nel qual caso le parti interessate non dovranno eseguire l'aggiornamento.
Più domini
Alcuni siti web utilizzano un dominio diverso solo per autenticare gli utenti che non sono idonei per i cookie dello stesso sito, ad esempio un sito web che utilizza example.com per il sito principale e login.example per il flusso di accesso, il che potrebbe richiedere l'accesso ai cookie di terze parti per garantire l'autenticazione dell'utente in entrambi i domini.
Alcune attività possono avere più prodotti ospitati su domini o sottodomini diversi. Queste soluzioni potrebbero voler condividere la sessione utente tra questi prodotti, uno scenario che potrebbe richiedere l'accesso ai cookie di terze parti tra più domini.
I possibili percorsi di migrazione per questo scenario sono:
- Aggiornamento per l'utilizzo dei cookie proprietari ("same-site"): modifica dell'infrastruttura del sito web in modo che il flusso di accesso sia ospitato nello stesso dominio (o sottodominio) del sito principale, che utilizzerà solo cookie proprietari. Questa operazione potrebbe richiedere uno sforzo maggiore, a seconda della configurazione dell'infrastruttura.
- Utilizza i set di siti web correlati (RWS) e l'API Storage Access (SAA): i set di siti web correlati consentono un accesso limitato ai cookie cross-site tra un piccolo gruppo di domini correlati. Con RWS, non è richiesta alcuna richiesta all'utente quando si richiede l'accesso allo spazio di archiviazione con l'API Accesso allo spazio di archiviazione. Ciò consente l'SSO per gli RP che si trovano nella stessa RWS dell'IdP. Tuttavia, RWS supporta l'accesso ai cookie cross-site solo su un numero limitato di domini.
- Utilizza l'API Web Authentication: l'API Web Authentication consente alle parti attendibili (RP) di registrare un insieme limitato di origini correlate in cui è possibile creare e utilizzare le credenziali.
- Se autentichi gli utenti in più di 5 domini associati, scopri Federated Credentials Management (FedCM): FedCM consente ai provider di identità di fare affidamento su Chrome per gestire i flussi relativi all'identità senza richiedere cookie di terze parti. Nel tuo caso, il "dominio di accesso" potrebbe fungere da provider di identità FedCM ed essere utilizzato per autenticare gli utenti negli altri tuoi domini.
Autenticazione dagli incorporamenti
Supponiamo che un iframe 3-party-app.example sia incorporato in top-level.example. Su 3-party-app.example, l'utente può accedere con le credenziali di 3-party-app.example o con un altro provider di terze parti.
L'utente fa clic su "Accedi" e si autentica nella finestra popup 3-party-app.example. Il popup 3-party-app.example imposta un cookie proprietario. Tuttavia, l'iframe 3-party-app.example incorporato in top-level.example è partizionato e non può accedere al cookie impostato nel contesto proprietario su 3-party-app.example.
Lo stesso problema si verifica quando un utente viene reindirizzato da top-level.example a 3-party-app.example e viceversa. Il cookie viene scritto nel contesto proprietario del sito 3-party-app.example, ma è partizionato e non è accessibile all'interno dell'iframe 3-party-app.example.
Se l'utente ha visitato l'origine incorporata in un contesto di primo livello, l'API Storage Access è una buona soluzione.
Per abbandonare le soluzioni che si basano sui cookie di terze parti, consigliamo ai provider di identità di adottare l'API FedCM e FedCM viene chiamato dagli incorporamenti interni anziché dai popup.
Un'altra soluzione proposta per questo flusso,i popin partizionati, è in fase di implementazione.
Accesso tramite social
I pulsanti di accesso, come Accedi con Google, Accesso a Facebook e Accedi con Twitter, sono un segnale definitivo che il tuo sito web utilizza un provider di identità federato. Ogni provider di identità federato avrà la propria implementazione.
Se utilizzi la libreria della piattaforma JavaScript ritirata di Accedi con Google, puoi trovare informazioni su come eseguire la migrazione alla più recente libreria dei Servizi di identità Google per l'autenticazione e l'autorizzazione.
La maggior parte dei siti che utilizzano la libreria più recente di Servizi di Google Identity ha rimosso la dipendenza dai cookie di terze parti, poiché la libreria eseguirà la migrazione in modo silenzioso all'utilizzo di FedCM per la compatibilità. Ti consigliamo di testare il tuo sito con l'indicatore di test per il ritiro graduale dei cookie di terze parti abilitato e, se necessario, di utilizzare l'elenco di controllo per la migrazione a FedCM per prepararti.
Accedere e modificare i dati utente dagli incorporamenti
I contenuti incorporati vengono spesso utilizzati per i percorsi degli utenti, ad esempio per accedere o gestire i dati del profilo o degli abbonamenti degli utenti.
Ad esempio, un utente potrebbe accedere a website.example, che incorpora un widget subscriptions.example. Questo widget consente agli utenti di gestire i propri dati, ad esempio abbonarsi a contenuti premium o aggiornare i dati di fatturazione. Per modificare i dati utente, il widget incorporato potrebbe dover accedere ai propri cookie durante l'incorporazione in website.example. Se questi dati devono essere isolati perwebsite.example, CHIPS può contribuire ad assicurare che l'embed possa accedere alle informazioni di cui ha bisogno. Con CHIPS, il widget subscriptions.example incorporato in website.example non avrà accesso ai dati dell'abbonamento dell'utente su altri siti web.
Consideriamo un altro caso: un video di streaming.example è incorporato in website.example e l'utente ha un abbonamento a streaming.example Premium, che il widget deve conoscere per disattivare gli annunci. Se è necessario accedere allo stesso cookie su più siti, ti consigliamo di utilizzare l'API Accesso allo spazio di archiviazione se l'utente ha visitato in precedenza streaming.example come sito di primo livello e i set di siti web correlati se l'insieme di website.example possiede streaming.example.
A partire da Chrome 131, FedCM è integrato con l'API Accesso allo spazio di archiviazione. Con questa integrazione, quando l'utente accetta la richiesta di FedCM, il browser concede all'IdP l'accesso incorporato allo spazio di archiviazione non partizionato.
Per ulteriori informazioni su quale API scegliere per gestire un determinato percorso dell'utente con contenuti incorporati, consulta la guida agli incorporamenti.
Accesso dall'esterno
La disconnessione dal canale frontale è un meccanismo che consente a un utente di disconnettersi da tutte le app correlate quando si disconnette da un servizio. La disconnessione nel canale anteriore di OIDC richiede all'IdP di incorporare diversi iframe della terza parte attendibile (RP) che si basano sui cookie della RP.
Se la tua soluzione si basa su un provider di identità, potrebbero essere necessarie modifiche minori (ad esempio un upgrade della libreria). Per ulteriori indicazioni, contatta il tuo provider di identità.
Per risolvere questo caso d'uso, FedCM ha sperimentato la funzionalità logoutRPs. In questo modo, l'IdP ha potuto uscire da qualsiasi RP per cui l'utente ha precedentemente approvato la comunicazione RP-IdP. Questa funzionalità non è più disponibile, ma ti invitiamo a dare un'occhiata alla proposta iniziale e a condividere con noi il tuo feedback se ti interessa o hai bisogno di questa funzionalità.
Altri percorsi degli utenti
I percorsi degli utenti che non si basano su cookie di terze parti non dovrebbero essere interessati dalle modifiche alle modalità di gestione dei cookie di terze parti in Chrome. Le soluzioni esistenti, come l'accesso, la disconnessione o il recupero dell'account nel contesto proprietario, la verifica in due passaggi, dovrebbero funzionare come previsto. I potenziali punti di malfunzionamento sono già stati descritti in precedenza. Per ulteriori informazioni su una determinata API, consulta la pagina dello stato dell'API. Segnala eventuali malfunzionamenti all'indirizzo goo.gle/report-3pc-broken. Puoi anche inviare un modulo di feedback o segnalare un problema su GitHub nel repository di assistenza per gli sviluppatori di Privacy Sandbox.
Controllare il sito
Se il tuo sito web implementa uno dei percorsi utente descritti in questa guida, devi assicurarti che i tuoi siti siano pronti: controlla l'utilizzo dei cookie di terze parti, verifica la presenza di errori e passa alle soluzioni consigliate.