Chrome propone una nuova esperienza di scelta dell'utente con i cookie di terze parti. Devi preparare il sito per gli utenti che scelgono di navigare senza cookie di terze parti.
In questa pagina troverai informazioni sugli scenari di accesso con maggiore probabilità essere interessati, nonché i riferimenti alle possibili soluzioni.
Se il tuo sito web gestisce solo flussi all'interno dello stesso dominio e dello stesso sottodominio, ad esempio
come publisher.example e login.publisher.example, non utilizzerà cross-site
non si prevede che i cookie e il flusso di accesso siano interessati dalle modifiche ai cookie di terze parti.
Tuttavia, se il sito utilizza un dominio separato per l'accesso, ad esempio Accedi con Google o Facebook oppure il tuo sito deve condividere le informazioni l'autenticazione su più domini o sottodomini, esiste la possibilità apportare modifiche al sito per garantire una transizione senza problemi cookie cross-site.
Verificare i percorsi degli utenti correlati all'identità
Il modo migliore per verificare se il flusso di accesso è influenzato dai cookie di terze parti modifiche consiste nel eseguire la registrazione, il recupero della password, l'accesso i flussi di uscita con il flag di test dei cookie di terze parti abilitato.
Questo è un elenco di controllo degli aspetti da verificare dopo aver applicato limitazioni alle app di terze parti cookie:
- 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 la navigazione in altri domini. Ricordati di testare ogni integrazione di accesso.
- Uscire:la procedura di disconnessione funziona come previsto e l'utente rimane. disconnesso dopo la procedura di uscita.
Devi inoltre verificare che le altre funzionalità del sito che richiedono l'accesso dell'utente rimangano funzionali senza cookie in più siti, soprattutto se prevedono il caricamento tra più siti. Ad esempio, se utilizzi una rete CDN per caricare le immagini del profilo degli utenti, per assicurarti che funzioni ancora. Se i percorsi degli utenti sono critici, ad esempio pagamento, effettuato all'accesso, assicurano che continuino a funzionare.
Nelle sezioni successive, troverai informazioni più specifiche su come si svolgono questi flussi potrebbero essere interessati.
Identità federata
I pulsanti di accesso come Accedi con Google, Accesso a Facebook e L'accesso con Twitter è la conferma definitiva che il tuo sito web utilizza una o provider di identità federato. Poiché ogni provider di identità federato avrà la sua implementazione, la soluzione migliore è controllare documentazione o contattali per ricevere ulteriori indicazioni.
Se utilizzi il cluster deprecato Nella libreria della piattaforma JavaScript Accedi con Google, puoi trovare informazioni su come per eseguire la migrazione alla più recente libreria dei Servizi di identità Google per l'autenticazione e autorizzazione.
La maggior parte dei siti che utilizzano la libreria dei Servizi di identità Google più recente è pronta per il ritiro dei cookie di terze parti, in quanto la libreria eseguirà automaticamente la migrazione utilizzando FedCM per verificare la compatibilità. Ti consigliamo di testare il tuo sito con il flag di test dei cookie di terze parti abilitato e, se necessario, utilizzando l'elenco di controllo per la migrazione a FedCM.
Dominio di accesso separato
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
e login.example per il flusso di accesso, che potrebbe richiedere l'accesso
cookie di terze parti per garantire che l'utente venga autenticato su entrambi
domini.
I possibili percorsi di migrazione per questo scenario sono:
- Aggiornamento per l'utilizzo dei cookie proprietari ("stesso sito"): modifica del parametro infrastruttura del sito web in modo che il flusso di accesso sia ospitato sullo stesso dominio (o ) come sito principale, che userà solo cookie proprietari. Questo può richiedono un impegno maggiore, a seconda di come è configurata l'infrastruttura.
- Utilizza insiemi di siti web correlati (RWS): insiemi di siti web correlati attivati un accesso limitato ai cookie cross-site tra un piccolo gruppo di domini correlati. RWS è un'API Privacy Sandbox creata per supportare questo caso d'uso. Tuttavia, solo RWS supporta l'accesso ai cookie tra siti su un numero limitato di domini.
- Se esegui l'autenticazione degli utenti su più di cinque domini associati, esplora FedCM: FedCM (Federated Credentials Management) consente ai provider di identità di affidarsi a Chrome per gestire i flussi correlati alle identità senza richiedono cookie di terze parti. Nel tuo caso, il "dominio di accesso" potrebbe agire come il provider di identità FedCM e da usare per autenticare gli utenti domini.
Più domini
Quando un'attività ha più prodotti ospitati su domini o sottodomini diversi, potrebbe voler condividere la sessione utente tra tutti i prodotti, uno scenario che potrebbe richiedono l'accesso a cookie di terze parti tra più domini.
In questo scenario, l'hosting di tutti i prodotti nello stesso dominio è spesso non è attuabile. Le possibili soluzioni in questo caso sono:
- Utilizza insiemi di siti web correlati: quando è necessario l'accesso ai cookie tra siti tra un piccolo gruppo di domini correlati.
- Usa Federation Credential Management (FedCM): quando il numero di dominio è di grandi dimensioni, puoi utilizzare un dominio di accesso separato che agisca da identità e autenticare gli utenti sui tuoi siti utilizzando FedCM.
Soluzioni di accesso
Single Sign-On (SSO) di terze parti
Data la complessità dell'implementazione di una soluzione SSO, molte aziende attivano questa funzionalità usando un provider di soluzioni di terze parti, per condividere lo stato di accesso tra più diverse origini dati. Esempi di provider includono Okta, Ping Identity, Google Cloud IAM o ID Microsoft Entra.
Quando si utilizza un fornitore di terze parti, l'approccio migliore consiste nel chiedere aiuto sul modo in cui le modifiche ai cookie di terze parti influiranno sulla soluzione e l'approccio che consigliano per il loro servizio.
Soluzioni SSO open source
Molte aziende che gestiscono le proprie soluzioni SSO utilizzano i sistemi standard di settore, come OpenID Connect, OAuth o SAML, o progetti di origine, come Keycloak, WSO2, Auth.js o Hydra.
Ti consigliamo di consultare la documentazione del tuo provider per capire le modifiche ai cookie potrebbero influire sulla loro soluzione e il percorso di migrazione migliore per quella specifica soluzione.
Soluzioni interne personalizzate
Se la tua soluzione di accesso rientra in uno dei casi d'uso precedenti ed è internamente, Preparati a ritirare gradualmente i cookie di terze parti spiega in maggiore dettaglio descrivere in dettaglio come eseguire la verifica del codice e come prepararsi alle modifiche dei cookie di terze parti.
Intervieni subito.
Se il tuo sito web rientra in uno dei casi d'uso, esistono più soluzioni disponibili per affrontare qualsiasi impatto possibile, dal trasferimento del flusso di autenticazione il dominio principale, quindi usa solo cookie proprietari, utilizzando Insiemi di siti web correlati per consentire la condivisione dei cookie tra un numero limitato di domini o sfruttando la gestione delle credenziali della federazione.
È il momento di controllare il tuo servizio e prepararti per il cookie di terze parti. modifiche è ora!