Controlla l'impatto delle modifiche dei cookie di terze parti sui flussi di lavoro di accesso

I cookie di terze parti potrebbero essere bloccati dalle limitazioni del browser, dalle impostazioni utente, dai flag per sviluppatori o dai criteri aziendali.

Il tuo sito o servizio deve offrire un'esperienza ottimale a tutti gli utenti, indipendentemente dalla disponibilità o meno dei cookie di terze parti.

In questa pagina troverai informazioni sugli scenari di identità più probabilmente interessati, nonché riferimenti a possibili soluzioni.

Se il tuo sito web gestisce solo flussi all'interno dello stesso dominio e sottodomini, ad esempio publisher.example e login.publisher.example, non utilizzerà cookie cross-site e non è previsto che il flusso di accesso venga interessato dalle modifiche ai cookie di terze parti.

Tuttavia, se il tuo sito utilizza un dominio separato per l'accesso, ad esempio con Google Sign-in o Facebook Login, o se il tuo sito deve condividere l'autenticazione utente su più domini o sottodomini, è possibile che tu debba apportare modifiche al tuo sito per garantire una transizione senza problemi dai cookie cross-site.

Percorsi dell'utente comuni

Storicamente, molti flussi di lavoro di identità si basavano su cookie di terze parti. La tabella elenca alcuni percorsi utente comuni e le potenziali soluzioni per ciascuno di questi che non dipendono dai cookie di terze parti. Le sezioni seguenti spiegheranno il motivo di questi consigli.

API alternative consigliate per i casi d'uso comuni

nella tabella si trovano nelle prime fasi di sviluppo. Il tuo feedback è prezioso e contribuirà a plasmare il loro futuro. Condividi la tua opinione su queste API: Partitioned Popins.

Testare i percorsi degli utenti correlati all'identità

Il modo migliore per verificare se il tuo flusso di accesso è interessato dalle modifiche ai cookie di terze parti è esaminare i flussi di registrazione, recupero della password, accesso e disconnessione con il flag di test dei cookie di terze parti abilitato.

Ecco un elenco di controllo degli aspetti da 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 password funziona come previsto, dall'interfaccia utente web, ai CAPTCHA, alla ricezione dell'email di recupero 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 dopo il flusso di disconnessione.

Devi anche verificare che le altre funzionalità del sito che richiedono l'accesso dell'utente rimangano funzionali senza cookie cross-site, soprattutto 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, ad esempio il pagamento, protetti da un 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 scelgono di utilizzare un fornitore di soluzioni di terze parti per condividere lo stato di accesso tra più origini. Alcuni esempi di provider 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 necessari alcuni cambiamenti minori, come un upgrade della libreria. L'approccio migliore è chiedere indicazioni al fornitore su come le dipendenze dei cookie di terze parti influenzano la soluzione e quale approccio consiglia per il suo servizio. Alcuni fornitori eseguiranno la migrazione silenziosa dai cookie di terze parti, nel qual caso le parti che fanno affidamento non devono eseguire l'aggiornamento.

Più domini

Alcuni siti web utilizzano un dominio diverso solo per autenticare gli utenti che non hanno i requisiti per i cookie proprietari, ad esempio un sito web che utilizza example.com per il sito principale e login.example per il flusso di accesso, che potrebbe richiedere l'accesso a cookie di terze parti per garantire che l'utente sia autenticato 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 a cookie di terze parti tra più domini.

I possibili percorsi di migrazione per questo scenario sono:

• Aggiornamento per l'utilizzo di cookie proprietari ("stesso sito"): modifica dell'infrastruttura del sito web in modo che il flusso di accesso sia ospitato nello stesso dominio (o in un sottodominio) del sito principale, che utilizzerà solo cookie proprietari. A seconda della configurazione dell'infrastruttura, questa operazione potrebbe richiedere un maggiore impegno.
• Utilizza gli insiemi di siti web correlati (RWS) e l'API Storage Access (SAA): gli RWS consentono l'accesso limitato ai cookie cross-site tra un piccolo gruppo di domini correlati. Con RWS, non è necessario richiedere l'accesso allo spazio di archiviazione con l'API Storage Access. Ciò consente l'SSO per le RP che si trovano nello stesso RWS dell'IdP. Tuttavia, l'insieme di siti web correlati 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 relying party (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, esplora Federated Credentials Management (FedCM): FedCM consente ai provider di identità di fare affidamento su Chrome per gestire i flussi correlati 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 domini.

Autenticazione dagli incorporamenti

Supponiamo che un iframe 3-party-app.example sia incorporato in top-level.example. Il giorno 3-party-app.example, l'utente può accedere con le credenziali 3-party-app.example o con un altro provider di terze parti.

L'utente fa clic su "Accedi" ed esegue l'autenticazione nel 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.

Nei casi in cui 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 su cookie di terze parti, consigliamo ai provider di identità di adottare l'API FedCM e FedCM viene chiamato dall'interno degli incorporamenti anziché dai popup.

Un'altra soluzione proposta per questo flusso, Partitioned Popins, è in fase di implementazione.

Accesso tramite social

I pulsanti di accesso come Accedi con Google, Accesso con Facebook e Accedi con Twitter sono un segno definitivo che il tuo sito web utilizza un provider di identità federata. Ogni provider di identità federata avrà la propria implementazione.

Se utilizzi la libreria della piattaforma JavaScript di Accedi con Google deprecata, puoi trovare informazioni su come eseguire la migrazione alla libreria più recente dei Servizi di identità Google per l'autenticazione e l'autorizzazione.

FedCM Ti consigliamo di testare il tuo sito con il flag di test per il ritiro dei cookie di terze parti attivato e, se necessario, di utilizzare la lista di controllo per la migrazione di FedCM per prepararti.

Accedere ai dati utente e modificarli dagli incorporamenti

I contenuti incorporati vengono spesso utilizzati per i percorsi utente, ad esempio per accedere o gestire i dati del profilo o degli abbonamenti utente.

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 mentre è incorporato in website.example. Nello scenario in cui questi dati devono essere isolati inwebsite.example, CHIPS può contribuire a garantire che l'incorporamento possa accedere alle informazioni di cui ha bisogno. Con CHIPS, il widget subscriptions.example incorporato su website.example non avrà accesso ai dati di abbonamento dell'utente su altri siti web.

Considera un altro caso: un video di streaming.example è incorporato in website.example e l'utente ha un abbonamento premium streaming.example, di cui il widget deve essere a conoscenza per disattivare gli annunci. Se è necessario accedere allo stesso cookie su più siti, valuta la possibilità di utilizzare l'API Storage Access se l'utente ha visitato in precedenza streaming.example come sito di primo livello e i set di siti web correlati se il set di website.example è proprietario di streaming.example.

A partire da Chrome 131, FedCM è integrata con l'API Storage Access. Con questa integrazione, quando l'utente accetta la richiesta FedCM, il browser concede all'incorporamento dell'IdP l'accesso allo spazio di archiviazione non partizionato.

Per ulteriori informazioni su quale API scegliere per gestire un particolare percorso dell'utente con contenuti incorporati, consulta la guida agli incorporamenti.

Altri percorsi utente

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 accesso, disconnessione o recupero dell'account nel contesto proprietario, autenticazione a due fattori, dovrebbero funzionare come previsto. I potenziali punti di rottura sono stati descritti in precedenza. Per ulteriori informazioni su una determinata API, consulta la pagina sullo stato dell'API.

Controllare il sito

Se il tuo sito web implementa uno dei percorsi utente descritti in questa guida, devi assicurarti che i tuoi siti siano preparati: controlla il tuo sito per verificare l'utilizzo di cookie di terze parti, esegui test per rilevare eventuali malfunzionamenti e passa alle soluzioni consigliate.