Come gestire il blocco dei cookie di terze parti nei browser

  • Articolo

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 il corretto accesso degli utenti. In Microsoft Identity Platform viene usato il flusso del codice 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. Questo flusso del codice di autorizzazione con l'approccio Chiave di prova per scambio codice è consigliato per il flusso implicito.

Che cosa sono 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 riguardano diversi domini, con Safari e Brave che 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. L'uso del flusso implicito nei contratti di servizio non è più consigliato a causa del blocco dei cookie di terze parti e dei relativi rischi per la sicurezza.

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 i 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:

Diagramma che mostra il flusso del codice di autorizzazione OAuth 2 tra un'app a pagina singola e l'endpoint del servizio token di sicurezza.

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 richiedono un reindirizzamento di pagina completo per l'accesso dell'utente, migliorando così le prestazioni e l'esperienza utente, in quanto 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 sono bloccati, le applicazioni devono regolare i codice di accesso per ottenere 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 che contengono la sessione utente ed è 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, per non scaricare completamente l'app 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.
    • Quando il popup termina il reindirizzamento all'applicazione dopo l'autenticazione, il codice nel gestore di reindirizzamento archivia il codice di autenticazione e i token nell'archivio locale per consentire all'applicazione di usarli. MSAL.js supporta i popup per l'autenticazione, così come la maggior parte delle librerie.
    • I browser stanno riducendo il supporto per i popup, quindi potrebbero non rappresentare l'opzione più affidabile. Per soddisfare i requisiti del browser, potrebbe essere necessaria l'interazione dell'utente con l'applicazione a pagina singola prima di creare il popup.

Apple descrive un metodo popup come correzione di compatibilità temporanea per concedere alla finestra originale l'accesso ai cookie di terze parti. Sebbene Apple possa rimuovere questo trasferimento di autorizzazioni in futuro, questo non avrà alcun effetto sulle indicazioni fornite in questo documento.

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 l’aspettativa di vedere un tasso più elevato di errori interacion_required quando i cookie di terze parti vengono bloccati. È consigliabile avere sempre un fallback del metodo interattivo, 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 sono bloccati. L'applicazione incorporata nell'iframe deve passare all'uso dei popup per accedere alla sessione dell'utente, perché non può passare alla pagina di accesso come un frame integrato.

È possibile ottenere l'accesso Single Sign-On tra app iframed e padre con accesso API script JavaScript di origine uguale e cross-origine 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 di token di aggiornamento, alle applicazioni a pagina singola sono emessi solo token validi 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 di pagina completo o un popup per ogni singolo token, ogni volta che un token scade (di norma ogni ora 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, poiché i cookie rimangono nello stesso dominio (ad esempio da 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: