Cachelagring i MSAL.js

När MSAL hämtar en token cachelagrar den för framtida användning. MSAL hanterar tokenlivslängder och uppdaterar åt dig. API:et acquireTokenSilent() hämtar åtkomsttoken från cachen för ett visst konto och förnyar dem om det behövs.

Cacheminneslagring

Du kan konfigurera lagringsplatsen för cachen via konfigurationsobjektet som används för att instansiera 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"
    }
});

Som standard lagrar MSAL de olika autentiseringsartefakter som hämtas från IdP:n i webbläsarlagringen med hjälp av webblagrings-API: et som stöds av alla moderna webbläsare. Därför erbjuder MSAL två metoder för beständig lagring: sessionStorage (standard) och localStorage. Dessutom tillhandahåller memoryStorage MSAL ett alternativ som gör att du kan välja bort lagring av cacheminnet i webbläsarens lagring.

Valet mellan olika lagringsplatser återspeglar en kompromiss mellan bättre användarupplevelse och ökad säkerhet. Som tabellen ovan anger ger lokal lagring bästa möjliga användarupplevelse, medan minneslagring ger den bästa säkerheten eftersom ingen känslig information lagras i webbläsarens lagring. Mer information finns i avsnittet om säkerhet och cachelagrade artefakter nedan.

LocalStorage-anteckningar

Från och med v4 krypteras autentiseringsartefakter om du använder localStorage cacheplatsen såvida inte användaren väljer "Håll mig inloggad" under inloggningen. Krypteringsalgoritmen som används är AES-GCM med HKDF för att härleda nyckeln. Basnyckeln lagras i en sessionscookie med titeln msal.cache.encryption.

Den här cookien tas bort automatiskt när webbläsarinstansen (inte fliken) stängs, vilket gör det omöjligt att dekryptera autentiseringsartefakter när sessionen har avslutats. Dessa utgångna autentiseringsartefakter tas bort nästa gång MSAL initieras och användaren kan behöva autentisera igen. Platsen localStorage ger fortfarande cachepersistence mellan flikar för alla användare men bevaras bara mellan webbläsarsessioner för användare som har valt "Håll mig inloggad" (KMSI).

Lagring av kakor

MSAL Browser kan konfigureras för att använda cookies för lagring av tillfälliga autentiseringsartefakter. Med det här alternativet kan du stödja webbläsare som kan rensa lokal lagring/sessionslagring under omdirigeringsbaserade inloggningsflöden (t.ex. Internet Explorer, Firefox i privat läge). Observera att när det här alternativet väljs lagras själva token fortfarande i webbläsaren eller i minneslagringen. Mer information finns i konfigurationen .

Security

Vi anser att session/lokal lagring är säker så länge ditt program inte har skript mellan platser (XSS) och relaterade säkerhetsrisker. Se OWASP XSS Prevention Cheat Sheet för att skydda dina program mot XSS. Om du fortfarande är orolig rekommenderar vi att du använder alternativet memoryStorage i stället.

Cachade artefakter

För att underlätta effektiv tokenanskaffning och samtidigt upprätthålla ett bra UX cachelagrar MSAL olika artefakter som är resultatet av dess API-anrop. Nedan visas en sammanfattning av entiteter i MSAL-cacheminnet:

• Beständiga artefakter (som kvarstår efter förfrågan – se även: tokenlivslängder)
  • åtkomsttoken
  • ID-token
  • uppdateringstoken
  • accounts
• Tillfälliga artefakter (begränsade till begärans livslängd)
  • metadata för begäran (t.ex. state, nonce, auktoritet)
  • Felaktigheter
  • interaktionsstatus
• Telemetri
  • tidigare misslyckad begäran
  • prestandauppgifter

temporaryCacheLocation åsidosättning

När du använder MSAL.js med standardkonfigurationen i ett scenario där användaren omdirigeras efter lyckad autentisering i ett nytt fönster eller en ny flik avbryts OAuth 2.0-auktoriseringskoden med PKCE-flödet. I det här fallet går det ursprungliga fönstret eller fliken där autentiseringstillståndet (kodverifieraren och utmaningen) lagras bort och autentiseringsflödet misslyckas.

Om du vill hantera det här scenariot kan du konfigurera MSAL att använda localStorage som cacheplats genom att åsidosätta konfigurationsegenskapen temporaryCacheLocation . Detta gör att kodverifieraren och utmaningen kan lagras i webbläsarens localStorage, som är beständig över flera flikar och fönster.

Beständighet för cache vid uppgraderingar och återgångar av MSAL.js

Ibland behöver MSAL.js göra ändringar i formen på de cachelagrade artefakterna för att stödja nya krav, funktioner eller felkorrigeringar. Så ofta som möjligt görs dessa ändringar på ett bakåtkompatibelt sätt för att säkerställa att cacheminnet som finns i en användares webbläsare fortfarande kan användas när ett program uppgraderas till en ny version eller återställs till en äldre version. Detta är dock inte alltid möjligt och du kan hamna i ett tillstånd där flera kopior av cacheminnet finns samtidigt, en som används av den aktuella versionen av MSAL.js som körs och en annan som skrevs av den version som användes före uppgraderingen. Detta görs för att applikationer ska kunna återgå på ett kontrollerat sätt, om det behövs. I de allra flesta uppgraderingar migrerar MSAL.js alla befintliga cacheminnen till det nya formatet för en sömlös uppgradering. I sällsynta fall, till exempel vid en uppgradering från v3 till v4, kanske det inte är möjligt på grund av säkerhets- eller integritetskrav, och detta resulterar alltid i en höjning av huvudversionsnumret.

När en icke-bakåtkompatibel cacheändring görs sparas den äldre cachen som standard i 5 dagar för att möjliggöra en återställning om det behövs. Hur lång tid det gamla cacheminnet sparas kan konfigureras med hjälp av cachekonfigurationen cacheRetentionDays på PublicClientApplication. Om cachen inte har använts aktivt inom den tiden rensas den nästa gång MSAL.js initieras. Dessutom, om du inte räknar med att behöva återgå till en tidigare version, kan du ange detta värde till 0 för att ange att den gamla cachen alltid ska tas bort omedelbart när du uppgraderar till en ny version av MSAL.js. Om du däremot har ett längre distributionsfönster för uppgraderingar kan du välja att ange detta till ett längre värde.

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

Remarks

• Vi rekommenderar inte att appar har affärslogik som är beroende av direkt användning av entiteter i cacheminnet. Använd i stället lämpligt MSAL-API när du behöver hämta token eller hämta konton.
• Nycklar som används för att kryptera poP-token (proof of possession) lagras med hjälp av en kombination av IndexedDB API och minneslagring. Mer information finns i access-token-proof-of-possession.

Mer information

• Hämta och cachelagra token med hjälp av Microsofts autentiseringsbibliotek