Come gestire il blocco dei cookie di terze parti nei browser

Molti browser bloccano i cookie di terze parti, i cookie sulle richieste ai domini diversi dal dominio visualizzato nella barra degli indirizzi del browser. Questi cookie sono noti anche come cookie tra domini. Questo blocco interrompe il flusso implicito e richiede nuovi modelli di autenticazione per consentire l'accesso degli utenti. In Microsoft Identity Platform viene usato il flusso di autorizzazione con La chiave di prova per Code Exchange (PKCE) e i token di aggiornamento per mantenere gli utenti connessi quando i cookie di terze parti vengono bloccati.

Che cos'è Intelligent Tracking Protection (ITP) e Privacy Sandbox?

Apple Safari offre una funzionalità di protezione della privacy abilitata per impostazione predefinita denominata Intelligent Tracking Protection o ITP. Chrome ha un'iniziativa sulla privacy del browser denominata Privacy Sandbox. Queste iniziative comprendono molte diverse attività di privacy del browser da parte dei browser e hanno sequenze temporali diverse. Entrambi gli sforzi bloccano i cookie di "terze parti" sulle richieste che interdominino, con Safari e Brave bloccano i cookie di terze parti per impostazione predefinita. Chrome ha recentemente annunciato che inizieranno a bloccare i cookie di terze parti per impostazione predefinita. Privacy Sandbox include modifiche all'archiviazione partizionata e al blocco dei cookie di terze parti.

Una forma comune di rilevamento delle azioni utente prevede il caricamento di un iframe in un sito di terze parti in background e l'utilizzo dei cookie per correlare l'utente nella rete Internet. Purtroppo, questo modello rappresenta anche la modalità standard di implementazione del flusso implicito nelle app a pagina singola. Un browser che blocca i cookie di terze parti per proteggere la privacy degli utenti può anche bloccare la funzionalità di un'applicazione a pagina singola.

La soluzione descritta in questo articolo funziona in tutti questi browser o ovunque i cookie di terze parti siano bloccati.

Panoramica della soluzione

Per continuare ad autenticare gli utenti nelle applicazioni a pagina singola, gli sviluppatori di app devono usare il flusso del codice di autorizzazione. Nel flusso del codice di autorizzazione, il provider di identità rilascia un codice e l'applicazione a pagina singola riscatta il codice per un token di accesso e un token di aggiornamento. Quando l'app richiede nuovi token, può usare il flusso del token di aggiornamento per ottenere nuovi token. Microsoft Authentication Library (MSAL) per JavaScript v2.0 e versioni successive implementa il flusso del codice di autorizzazione per le applicazioni a pagina singola e, con aggiornamenti secondari, è una sostituzione di MSAL.js 1.x. Vedere la guida alla migrazione per lo spostamento di un'applicazione a pagina singola dal flusso implicito al flusso del codice di autenticazione.

Per Microsoft Identity Platform, le applicazioni a pagina singola e i client nativi seguono indicazioni simili in merito al protocollo:

• Uso di una richiesta di verifica del codice PKCE
  • L'estensione PKCE è obbligatoria per le applicazioni a pagina singola in Microsoft Identity Platform. L'estensione PKCE è consigliata per client nativi e riservati.
• Nessun utilizzo di un segreto client

Le licenze a livello di servizio hanno altre due restrizioni:

• L'URI di reindirizzamento deve essere contrassegnato come tipo spa per abilitare CORS sugli endpoint di accesso.
• I token di aggiornamento rilasciati tramite il flusso del codice di autorizzazione agli URI di reindirizzamento spa prevedono una durata di 24 ore anziché una durata di 90 giorni.

Prestazioni e implicazioni per l'esperienza utente

Alcune applicazioni che usano il flusso implicito tentano l'accesso senza reindirizzamento aprendo un iframe di accesso con prompt=none. Nella maggior parte dei browser questa richiesta risponde con i token per l'utente attualmente connesso (presupponendo che venga concesso il consenso). Questo modello significa che le applicazioni non hanno bisogno di un reindirizzamento a pagina completa per l'accesso dell'utente, migliorando le prestazioni e l'esperienza utente: l'utente visita la pagina Web ed è già connesso. Poiché prompt=none in un iframe non è più un'opzione quando i cookie di terze parti vengono bloccati, le applicazioni devono modificare i modelli di accesso in modo che venga emesso un codice di autorizzazione.

Senza cookie di terze parti, esistono due modi per eseguire l'accesso:

• Reindirizzamenti di pagina completi
  • Al primo caricamento dell'applicazione a pagina singola, l'utente viene reindirizzato alla pagina di accesso, se non esiste già una sessione o se la sessione è scaduta. Il browser dell'utente visita la pagina di accesso, presenta i cookie contenenti la sessione utente e viene quindi reindirizzato all'applicazione con il codice e i token in un frammento.
  • Durante questa procedura di reindirizzamento, l'applicazione a pagina singola viene caricata due volte. Seguire le procedure consigliate per la memorizzazione nella cache delle applicazioni a pagina singola in modo che l'app non venga scaricata due volte.
  • È consigliabile definire nell'app una sequenza di precaricamento che verifichi la presenza di una sessione di accesso e reindirizzi alla pagina di accesso prima che l'app venga decompressa completamente ed esegua il payload JavaScript.
• Popup
  • Se l'esperienza utente di un reindirizzamento di pagina completo non funziona per l'applicazione, è consigliabile usare un popup per gestire l'autenticazione.
  • Al termine del reindirizzamento all'applicazione dopo l'autenticazione, il codice nel gestore di reindirizzamento archivierà il codice di autenticazione e i token nella risorsa di archiviazione locale per l'applicazione da usare. MSAL.js supporta i popup per l'autenticazione, così come la maggior parte delle librerie.
  • I browser riducono il supporto per i popup, quindi potrebbero non essere l'opzione più affidabile. L'interazione dell'utente con l'applicazione a pagina singola prima di creare il popup potrebbe essere necessario per soddisfare i requisiti del browser.

Apple descrive un metodo popup come correzione di compatibilità temporanea per concedere alla finestra originale l'accesso ai cookie di terze parti. Anche se Apple potrebbe rimuovere questo trasferimento di autorizzazioni in futuro, non avrà alcun impatto sulle indicazioni riportate qui.

In questo caso, il popup viene usato come finestra di passaggio alla pagina di accesso, per trovare una sessione e consentire il rilascio di un codice di autorizzazione. Questa soluzione dovrebbe continuare a funzionare anche in futuro.

Gli sviluppatori possono continuare a usare prompt=none con le aspettative che vedono un tasso più elevato di errori di interacion_required quando i cookie di terze parti vengono bloccati. È consigliabile avere sempre un fallback interattivo del metodo, se si verificano errori durante l'acquisizione automatica dei token.

Uso di iframe

Un modello comune nelle app Web consiste nell'usare un iframe per incorporare un'app all'interno di un'altra: il frame di primo livello gestisce l'autenticazione dell'utente e l'applicazione ospitata nell'iframe può considerare attendibile che l'utente ha eseguito l'accesso, recuperando i token in modo invisibile all'utente usando il flusso implicito. Tuttavia, ci sono un paio di avvertenze a questo presupposto indipendentemente dal fatto che i cookie di terze parti siano abilitati o bloccati nel browser.

L'acquisizione di token invisibile all'utente non funziona più quando i cookie di terze parti vengono bloccati. L'applicazione incorporata nell'iframe deve passare all'uso di popup per accedere alla sessione dell'utente perché non può passare alla pagina di accesso all'interno di un frame incorporato.

È possibile ottenere l'accesso Single Sign-On tra app iframed e padre con accesso api script JavaScript di origine e cross-origin passando un hint utente (account) dall'app padre all'app iframed. Per altre informazioni, vedere Uso di MSAL.js nelle app iframe nel repository MSAL.js su GitHub.

Implicazioni per la sicurezza dei token di aggiornamento nel browser

Gli attacchi di tipo cross-site scripting XSS (cross-site scripting) o i pacchetti JS compromessi possono rubare il token di aggiornamento e usarlo in modalità remota fino alla scadenza o alla revoca. Gli sviluppatori di applicazioni sono responsabili della riduzione del rischio dell'applicazione per lo scripting tra siti. Per ridurre al minimo il rischio di furto dei token di aggiornamento, i token di servizio vengono emessi solo per 24 ore. Dopo 24 ore, l'app deve acquisire un nuovo codice di autorizzazione tramite una visita del frame di primo livello alla pagina di accesso.

Questo modello di token di aggiornamento a durata limitata è stato scelto come compromesso tra la sicurezza e un'esperienza utente con prestazioni non ottimali. Senza i token di aggiornamento o i cookie di terze parti, il flusso del codice di autorizzazione (come consigliato dalla bozza di procedure consigliate per la sicurezza di OAuth) diventa oneroso quando sono necessari token nuovi o aggiuntivi. È necessario un reindirizzamento o un popup a pagina completa per ogni singolo token, ogni volta che un token scade (ogni ora, in genere, per i token di Microsoft Identity Platform).

Mitigazioni specifiche del tipo di utente

Non tutti gli utenti e le applicazioni sono interessati in modo uniforme dai cookie di terze parti. Esistono alcuni scenari in cui, a causa dell'architettura o della gestione dei dispositivi, è possibile eseguire chiamate invisibile all'utente per rinnovare i token senza cookie di terze parti.

Per gli scenari di dispositivi aziendali gestiti, alcune combinazioni di browser e piattaforma supportano l'accesso condizionale del dispositivo. L'applicazione dell'identità del dispositivo riduce al minimo la necessità di cookie di terze parti perché lo stato di autenticazione può provenire dal dispositivo anziché dal browser.

Per gli scenari di applicazione Azure AD B2C, i clienti possono configurare un dominio di accesso personalizzato in modo che corrisponda al dominio dell'applicazione. I browser non bloccano i cookie di terze parti in questo scenario perché i cookie rimangono nello stesso dominio (ad esempio, login.contoso.com a app.contoso.com).

Limitazioni sulla disconnessione front-channel senza cookie di terze parti

Quando si disconnette un utente da un'applicazione a pagina singola, MSAL.js consiglia di usare il metodo di disconnessione popup o reindirizzamento. Anche se ciò cancella la sessione di autenticazione nel server e nell'archiviazione del browser, esiste il rischio che senza accesso ai cookie di terze parti, non tutte le applicazioni federate visualizzeranno una disconnessa contemporaneamente. Si tratta di una limitazione nota della specifica OpenID Front-Channel Logout 1.0. Ciò significa che per gli utenti i token di accesso esistenti per altre applicazioni per lo stesso utente continueranno a essere validi fino alla scadenza. Un utente potrebbe disconnettersi dall'applicazione A nella scheda A, ma l'applicazione B nella scheda B verrà comunque visualizzata come connesso per il tempo valido rimanente del token di accesso. Quando il token dell'applicazione B scade e viene effettuata una chiamata al server per ottenere un nuovo token, l'applicazione B riceve una risposta dal server che la sessione è scaduta e chiede all'utente di eseguire l'autenticazione.

La pagina di disconnessione di Microsoft e le procedure consigliate per la privacy internet consigliano agli utenti di chiudere tutte le finestre del browser dopo la disconnessione da un'applicazione.

Passaggi successivi

Per altre informazioni sul flusso del codice di autorizzazione e sulle MSAL.js, vedere:

• Flusso del codice di autorizzazione.
• MSAL.js 2.0 guida introduttiva.