Gestire ITP in Safari e in altri browser in cui i cookie di terze parti sono bloccati

  • 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. Questo blocco interrompe il flusso implicito e richiede nuovi modelli di autenticazione per consentire l'accesso degli utenti. Nel Microsoft Identity Platform viene usato il flusso di autorizzazione con Proof Key for 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)?

Apple Safari offre una funzionalità di protezione della privacy abilitata per impostazione predefinita denominata Intelligent Tracking Protection o ITP. ITP blocca i cookie "di terze parti", ovvero i cookie sulle richieste tra domini.

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. Quando un browser blocca i cookie di terze parti per impedire il rilevamento delle azioni utente, vengono interrotte anche le applicazioni a pagina singola.

Safari non è l'unico browser che blocca i cookie di terze parti per tutelare la privacy degli utenti. Brave blocca i cookie di terze parti per impostazione predefinita e Chromium (la piattaforma dietro Google Chrome e Microsoft Edge) ha annunciato che non supporteranno i cookie di terze parti in futuro.

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 implementa il flusso del codice di autorizzazione per le applicazioni a pagina singola e, con aggiornamenti secondari, è una sostituzione di MSAL.js 1.x.

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 applicazioni 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 risponderà con i token per l'utente attualmente connesso (presupponendo che sia già stato 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 sono bloccati, le applicazioni devono visitare la pagina di accesso in un frame di primo livello per ottenere un codice di autorizzazione.

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 e quindi reindirizza l'utente 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 e i token nell'archiviazione locale per l'applicazione da usare. 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. Anche se Apple può 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.

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 sia connesso, recuperando i token in modo invisibile all'utente usando il flusso implicito. Tuttavia, ci sono due 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.

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

Implicazioni per la sicurezza dei token di aggiornamento nel browser

Il rilascio dei token di aggiornamento al browser è considerato un problema di sicurezza. 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. Per ridurre al minimo il rischio di furto di token di aggiornamento, alle applicazioni a pagina singola verranno rilasciati token validi solo 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 intera per ogni singolo token, ogni volta che un token scade (ogni ora, in genere, per i token di Microsoft Identity Platform).

Passaggi successivi

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