Gestione della cache in MSAL.js

Quando MSAL acquisisce un token, lo memorizza nella cache per un utilizzo futuro. MSAL gestisce automaticamente la durata dei token e l'aggiornamento. L'API acquireTokenSilent() recupera i token di accesso dalla cache per un determinato account e li rinnova, se necessario.

Archiviazione cache

È possibile configurare il percorso di archiviazione della cache tramite l'oggetto di configurazione usato per creare un'istanza di MSAL:

import { PublicClientApplication, BrowserCacheLocation } from "@azure/msal-browser";

const pca = new PublicClientApplication({
    auth: {
        clientId: "Enter_the_Application_Id_Here", // e.g. "00001111-aaaa-2222-bbbb-3333cccc4444" (guid)
        authority: "https://login.microsoftonline.com/Enter_the_Tenant_Info_Here", // e.g. "common" or your tenantId (guid),
        redirectUri: "/"
    },
    cache: {
       cacheLocation: BrowserCacheLocation.SessionStorage // "sessionStorage"
    }
});

Per impostazione predefinita, MSAL archivia i vari artefatti di autenticazione ottenuti dal provider di identità nell'archiviazione del browser usando l'API di archiviazione Web supportata da tutti i browser moderni. Di conseguenza, MSAL offre due metodi di archiviazione permanente: sessionStorage (impostazione predefinita) e localStorage. INOLTRE, MSAL offre memoryStorage l'opzione che consente di rifiutare esplicitamente di archiviare la cache nell'archiviazione del browser.

La scelta tra posizioni di archiviazione diverse riflette un compromesso tra un'esperienza utente migliore e una maggiore sicurezza. Come indicato nella tabella precedente, l'archiviazione locale offre un'esperienza utente ottimale, mentre l'archiviazione della memoria offre la migliore sicurezza poiché non sono archiviate informazioni riservate nell'archiviazione del browser. Per altre informazioni, vedere la sezione relativa alla sicurezza e agli artefatti memorizzati nella cache .

Note su LocalStorage

A partire dalla versione 4, se si usa il percorso della localStorage cache, gli artefatti di autenticazione vengono crittografati a meno che l'utente non selezioni "Mantieni l'accesso" durante l'accesso. L'algoritmo di crittografia usato è AES-GCM usando HKDF per derivare la chiave. La chiave di base viene archiviata in un cookie di sessione denominato msal.cache.encryption.

Questo cookie viene rimosso automaticamente quando l'istanza del browser (non la scheda) viene chiusa, rendendo impossibile decrittografare eventuali artefatti di autenticazione al termine della sessione. Questi artefatti di autenticazione scaduti vengono rimossi alla successiva inizializzazione di MSAL e l'utente potrebbe dover ripetere l'autenticazione. La localStorage posizione fornisce comunque la persistenza della cache tra schede per tutti gli utenti, ma viene mantenuta solo tra le sessioni del browser per gli utenti che hanno selezionato "Mantieni l'accesso" (KMSI).

Archiviazione dei cookie

È possibile configurare MSAL Browser per l'uso di cookie per l'archiviazione di artefatti di autenticazione temporanei. Questa opzione consente di supportare browser che possono cancellare l'archiviazione locale/sessione durante i flussi di accesso basati sul reindirizzamento (ad esempio, Internet Explorer, Firefox in modalità privata). Si noti che quando si sceglie questa opzione, i token stessi vengono ancora archiviati nel browser o nell'archiviazione di memoria. Per altre informazioni, vedere configurazione .

Security

L'archiviazione locale/sessione viene considerata sicura, purché l'applicazione non disponga di scripting tra siti (XSS) e vulnerabilità correlate. Fare riferimento al OWASP XSS Prevention Cheat Sheet per proteggere le vostre applicazioni dagli attacchi XSS. Se si è ancora preoccupati, è consigliabile usare l'opzione memoryStorage .

Elementi memorizzati nella cache

Per facilitare l'acquisizione efficiente dei token mantenendo un'esperienza utente ottimale, MSAL memorizza nella cache vari artefatti risultanti dalle chiamate API. Di seguito è riportato un riepilogo delle entità nella cache MSAL:

• Artefatti durevoli (che persistono dopo la richiesta -vedi anche: durata dei token)
  • token di accesso
  • token di identificazione
  • token di aggiornamento
  • accounts
• Artefatti effimeri (limitati alla durata della richiesta)
  • metadati della richiesta (ad esempio, stato, nonce, autorità)
  • errori
  • stato di interazione
• Telemetria
  • richiesta precedente non riuscita
  • dati sulle prestazioni

sovrascrittura di temporaryCacheLocation

Quando si usa MSAL.js con la configurazione predefinita in uno scenario in cui l'utente viene reindirizzato dopo l'autenticazione riuscita in una nuova finestra o scheda, il codice di autorizzazione OAuth 2.0 con il flusso PKCE verrà interrotto. In questo caso, la finestra o la scheda originale in cui vengono archiviati lo stato di autenticazione (verifica del codice e verifica) andrà perso e il flusso di autenticazione avrà esito negativo.

Per gestire questo scenario, è possibile configurare MSAL da usare localStorage come percorso della cache eseguendo l'override della temporaryCacheLocation proprietà di configurazione. Ciò consente di memorizzare il code verifier e il challenge nel localStorage del browser, che è persistente tra più schede e finestre.

Persistenza della cache durante gli aggiornamenti e i rollback di MSAL.js

Occasionalmente, MSAL.js deve apportare modifiche alla struttura degli artefatti memorizzati nella cache per supportare nuovi requisiti, funzionalità o correzioni di bug. Il più spesso possibile, queste modifiche vengono apportate in modo compatibile con le versioni precedenti in modo da garantire che quando un'applicazione viene aggiornata a una nuova versione o ne esegue il rollback a una versione precedente, la cache presente nel browser di un utente può comunque essere usata. Tuttavia, questo non è sempre possibile e si potrebbe finire in uno stato in cui esistono più copie della cache contemporaneamente, una usata dalla versione corrente di MSAL.js in esecuzione e un'altra scritta dalla versione usata prima dell'aggiornamento. Questa operazione viene eseguita per consentire alle applicazioni di eseguire correttamente il rollback, se necessario. Nella maggior parte degli aggiornamenti, MSAL.js esegue la migrazione di qualsiasi cache esistente nel nuovo formato per un'esperienza di aggiornamento senza problemi. In casi rari, come l'aggiornamento dalla v3 alla v4, questo potrebbe non essere possibile a causa di requisiti di sicurezza o di privacy e ciò comporta sempre un incremento della versione principale.

Quando viene apportata una modifica incompatibile della cache, per impostazione predefinita la cache precedente viene mantenuta per 5 giorni, per consentire un rollback, se necessario. Il periodo di memorizzazione della vecchia cache può essere configurato usando la configurazione della cacheRetentionDays cache in PublicClientApplication. Se la cache non è stata usata attivamente in quel momento, viene cancellata la volta successiva MSAL.js viene inizializzata. Inoltre, se non si prevede di eseguire il rollback, è possibile impostare questo valore su 0 per indicare che la vecchia cache deve essere sempre rimossa immediatamente dopo l'aggiornamento a una nuova versione di MSAL.js. Viceversa, se si dispone di una finestra di implementazione più lunga per gli aggiornamenti, è possibile scegliere di impostare questo valore su un valore più lungo.

const config = {
    auth: {
        clientId: "<your-client-id>"
    },
    cache: {
        cacheLocation: "localStorage",
        cacheRetentionDays: 0 // Set this to the number of days you want old cache to be preserved in the event a rollback is needed (Default 5 days)
    }
}

const pca = new PublicClientApplication(config);
await pca.initialize();

Commenti

• Non consigliamo che le app abbiano una logica di business dipendente dall'uso diretto delle entità nella cache. Usare invece l'API MSAL appropriata quando è necessario acquisire token o recuperare gli account.
• Le chiavi usate per crittografare i token poP (Proof of Possession) vengono archiviate usando una combinazione di API IndexedDB e archiviazione di memoria. Per altre informazioni, vedere access-token-proof-of-possession.

Altre informazioni

• Acquisire e memorizzare nella cache i token usando il Libreria di Autenticazione Microsoft