Mise en cache dans MSAL.js

Lorsque MSAL acquiert un jeton, il le met en cache pour une utilisation ultérieure. MSAL gère les durées de vie des jetons et leur actualisation pour vous. L’API acquireTokenSilent() récupère les jetons d’accès du cache pour un compte donné et les renouvelle si nécessaire.

Stockage du cache

Vous pouvez configurer l’emplacement de stockage du cache via l’objet de configuration utilisé pour instancier 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"
    }
});

Par défaut, MSAL stocke les différents artefacts d’authentification qu’il obtient auprès du fournisseur d’identité dans le stockage du navigateur à l’aide de l’API Stockage Web prise en charge par tous les navigateurs modernes. En conséquence, MSAL offre deux méthodes de stockage persistant : sessionStorage (par défaut) et localStorage. En outre, MSAL fournit une memoryStorage option qui vous permet de désactiver le stockage du cache dans le stockage du navigateur.

Le choix entre différents emplacements de stockage reflète un compromis entre une meilleure expérience utilisateur et une sécurité accrue. Comme le tableau ci-dessus indique que le stockage local entraîne la meilleure expérience utilisateur possible, tandis que le stockage de mémoire offre la meilleure sécurité, car aucune information sensible n’est stockée dans le stockage du navigateur. Pour plus d’informations, consultez la section relative à la sécurité et aux artefacts mis en cache ci-dessous.

Notes sur LocalStorage

À compter de la version v4, si vous utilisez l’emplacement du localStorage cache, les artefacts d’authentification sont chiffrés, sauf si l’utilisateur sélectionne « Conserver la connexion » pendant la connexion. L’algorithme de chiffrement utilisé est AES-GCM à l’aide de HKDF pour dériver la clé. La clé de base est stockée dans un cookie de session intitulé msal.cache.encryption.

Ce cookie est automatiquement supprimé lorsque l’instance du navigateur (et non l’onglet) est fermée, ce qui rend impossible le déchiffrement des artefacts d’authentification une fois la session terminée. Ces artefacts d’authentification expirés sont supprimés la prochaine fois que MSAL est initialisé et que l’utilisateur peut avoir besoin de réauthentifier. L’emplacement localStorage fournit toujours la persistance du cache entre les onglets pour tous les utilisateurs, mais celle-ci ne persiste d’une session de navigateur à l’autre que pour les utilisateurs qui ont sélectionné « Maintenir la connexion » (KMSI).

Stockage des cookies

MSAL Browser peut être configuré pour utiliser des cookies pour stocker des artefacts d’authentification temporaires. Cette option vous permet de prendre en charge les navigateurs qui peuvent effacer le stockage local/session pendant les flux de connexion basés sur la redirection (par exemple, Internet Explorer, Firefox en mode privé). Notez que lorsque cette option est choisie, les jetons eux-mêmes sont toujours stockés dans le navigateur ou le stockage mémoire. Pour plus d’informations, reportez-vous à la configuration .

Sécurité

Nous considérons le stockage de session/local sécurisé tant que votre application n’a pas de scripts intersites (XSS) et des vulnérabilités associées. Reportez-vous à la Aide-mémoire de prévention OWASP XSS pour sécuriser vos applications contre XSS. Si vous êtes toujours inquiet, nous vous recommandons d’utiliser l’option memoryStorage à la place.

Artefacts mis en cache

Pour faciliter l’acquisition de jetons efficace tout en conservant une bonne expérience utilisateur, MSAL met en cache différents artefacts résultant de ses appels d’API. Voici un résumé des entités dans le cache MSAL :

• Artefacts durables (qui persistent après la requête - voir aussi : durée de vie des jetons)
  • jetons d’accès
  • jetons d’ID
  • jetons d’actualisation
  • comptes
• Artefacts éphémères (limités à la durée de vie de la demande)
  • demander des métadonnées (par exemple, état, nonce, autorité)
  • Erreurs
  • état de l’interaction
• Télémétrie
  • demande ayant échoué précédente
  • données de performances

Substitution de temporaryCacheLocation

Lorsque vous utilisez MSAL.js avec la configuration par défaut dans un scénario où l’utilisateur est redirigé après l’authentification réussie dans une nouvelle fenêtre ou un nouvel onglet, le code d’autorisation OAuth 2.0 avec le flux PKCE est interrompu. Dans ce cas, la fenêtre ou l’onglet d’origine où l’état d’authentification (vérificateur de code et défi) est stocké, sera perdu et le flux d’authentification échouera.

Pour gérer ce scénario, vous pouvez configurer MSAL pour qu’il utilise localStorage comme emplacement du cache en remplaçant la temporaryCacheLocation propriété de configuration. Cela permet de stocker le vérificateur de code et le challenge dans le localStorage du navigateur, qui reste persistant entre plusieurs onglets et fenêtres.

Conservation du cache lors des mises à niveau de MSAL.js et des retours à une version antérieure

Parfois, MSAL.js doit apporter des modifications à la forme des artefacts mis en cache pour prendre en charge de nouvelles exigences, fonctionnalités ou correctifs de bogues. Le plus souvent possible, ces modifications sont apportées de manière rétrocompatible afin de s’assurer que lorsqu’une application effectue une mise à niveau vers une nouvelle version ou est rétablie vers une version antérieure, le cache présent dans le navigateur d’un utilisateur peut toujours être utilisé. Toutefois, cela n’est pas toujours possible et vous pouvez finir dans un état où plusieurs copies du cache existent simultanément, une utilisée par la version actuelle de MSAL.js en cours d’exécution et une autre écrite par la version utilisée avant la mise à niveau. Cela permet aux applications de revenir proprement à une version antérieure si nécessaire. Dans la grande majorité des mises à niveau, MSAL.js migre tout cache existant dans le nouveau format pour une expérience de mise à niveau transparente. Dans de rares cas, comme la mise à niveau de v3 vers v4, cela peut ne pas être possible en raison des exigences de sécurité ou de confidentialité, et cela entraîne toujours une panne de version majeure.

Lorsqu'une modification cassante du cache est introduite, l'ancien cache est conservé pendant 5 jours par défaut afin de permettre un retour en arrière si nécessaire. La durée pendant laquelle l’ancien cache est conservé peut être configuré à l’aide de la configuration du cacheRetentionDays cache sur PublicClientApplication. Si le cache n’a pas été utilisé activement dans ce temps, il est effacé la prochaine fois que MSAL.js est initialisé. En outre, si vous ne prévoyez pas de revenir à une version antérieure, vous pouvez définir cette valeur sur 0 pour indiquer que l’ancien cache doit toujours être supprimé immédiatement lors de la mise à niveau vers une nouvelle version de MSAL.js. À l’inverse, si vous disposez d’une fenêtre de déploiement plus longue pour les mises à niveau, vous pouvez choisir de définir cette valeur sur une valeur plus longue.

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();

Remarques

• Nous déconseillons les applications ayant une logique métier dépendante de l’utilisation directe d’entités dans le cache. Utilisez plutôt l’API MSAL appropriée lorsque vous devez acquérir des jetons ou récupérer des comptes.
• Les clés utilisées pour chiffrer les jetons de possession (PoP) sont stockées à l’aide d’une combinaison de l’API IndexedDB et du stockage de mémoire. Pour plus d’informations, veuillez vous reporter à access-token-proof-of-possession.

Plus d’informations

• Acquérir et mettre en cache des jetons à l’aide du Microsoft Authentication Library