Chrome propone una nuova esperienza per la 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 flussi all'interno dello stesso dominio e dei relativi sottodomini, ad esempio publisher.example e login.publisher.example, non utilizzerà i cookie cross-site e il flusso di accesso non dovrebbe essere 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 comuni degli utenti
In passato, molti flussi di lavoro per le 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 con 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 + SAA |
|
API Accesso allo spazio di archiviazione Set di siti web correlati CHIPS FedCM + SAA |
|
| Autenticazione |
API Accesso allo spazio di archiviazione FedCM API di autenticazione web sciencePopup partizionati |
| 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 di 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 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 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. Ciò 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. In questo modo è possibile utilizzare il 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 su 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 di 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 eseguire la migrazione dalle soluzioni che si basano sui cookie di terze parti, consigliamo ai provider di identità di adottare l'API FedCM e di chiamare FedCM dall'interno degli elementi incorporati anziché dai popup.
Un'altra soluzione proposta per questo flusso,i popup suddivisi, è in fase di implementazione.
Accesso social
I pulsanti di accesso come Accedi con Google, Accedi con Facebook e Accedi con Twitter sono un segno inequivocabile che il tuo sito web utilizza un identity provider federato. Ogni provider di identità federato avrà la propria implementazione.
Se utilizzi la libreria della piattaforma JavaScript di Accedi con Google ritirata, puoi trovare informazioni su come eseguire la migrazione alla nuova libreria dei Servizi di identità Google per l'autenticazione e l'autorizzazione.
La maggior parte dei siti che utilizzano la nuova libreria Servizi di identità Google 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 ai dati utente e modificarli dagli elementi incorporati
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 nel canale principale è un meccanismo che consente a un utente di uscire da tutte le app correlate quando esce 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 raccolta). 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 utente che non si basano su cookie di terze parti non dovrebbero essere interessati dalle modifiche al modo in cui Chrome gestisce i cookie di terze parti. 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 rottura sono 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.