Opslaan in cache in MSAL.js

Wanneer MSAL een token verkrijgt, wordt het in de cache opgeslagen voor toekomstig gebruik. MSAL beheert voor u de levensduur van tokens en het vernieuwen ervan. De acquireTokenSilent() API haalt toegangstokens op uit de cache voor een bepaald account en vernieuwt deze indien nodig.

Cacheopslag

U kunt de cacheopslaglocatie configureren via het configuratieobject dat wordt gebruikt om MSAL te instantiëren:

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"
    }
});

Standaard slaat MSAL de verschillende verificatieartefacten op die het verkrijgt van de IdP in browseropslag met behulp van de Web Storage-API die wordt ondersteund door alle moderne browsers. Daarom biedt MSAL twee methoden voor permanente opslag: sessionStorage (standaard) en localStorage. Daarnaast biedt MSAL een memoryStorage optie waarmee u zich kunt afmelden voor het opslaan van de cache in browseropslag.

De keuze tussen verschillende opslaglocaties weerspiegelt een afweging tussen een betere gebruikerservaring versus een betere beveiliging. Zoals in de bovenstaande tabel wordt aangegeven, resulteert lokale opslag in de best mogelijke gebruikerservaring, terwijl geheugenopslag de beste beveiliging biedt, omdat er geen gevoelige informatie wordt opgeslagen in browseropslag. Zie de sectie over beveiligings - en cacheartefacten hieronder voor meer informatie.

LocalStorage-aantekeningen

Vanaf v4 worden verificatieartefacten versleuteld als u de localStorage cachelocatie gebruikt, tenzij de gebruiker 'Aangemeld blijven' selecteert tijdens het aanmelden. Het gebruikte versleutelingsalgoritmen zijn AES-GCM met behulp van HKDF om de sleutel af te leiden. De basissleutel wordt opgeslagen in een sessiecooky met msal.cache.encryptionde titel .

Deze cookie wordt automatisch verwijderd wanneer het browserexemplaren (geen tabblad) wordt gesloten, waardoor het onmogelijk is om verificatieartefacten te ontsleutelen nadat de sessie is beëindigd. Deze verlopen verificatieartefacten worden verwijderd wanneer MSAL de volgende keer wordt geïnitialiseerd en de gebruiker moet mogelijk opnieuw verifiëren. De localStorage locatie biedt nog steeds persistentie op meerdere tabbladen voor alle gebruikers, maar blijft alleen bestaan in browsersessies voor gebruikers die KMSI (Aangemeld blijven) hebben geselecteerd.

Cookieopslag

MSAL Browser kan worden geconfigureerd voor het gebruik van cookies voor het opslaan van tijdelijke verificatieartefacten. Met deze optie kunt u browsers ondersteunen die lokale/sessieopslag mogelijk wissen tijdens aanmeldingsstromen op basis van omleiding (bijvoorbeeld Internet Explorer, Firefox in de privémodus). Wanneer deze optie is gekozen, worden tokens zelf nog steeds opgeslagen in de browser- of geheugenopslag. Raadpleeg de configuratie voor meer informatie.

Security

We overwegen sessie-/lokale opslag te beveiligen zolang uw toepassing geen XSS (Cross-Site Scripting) en gerelateerde beveiligingsproblemen heeft. Raadpleeg het cheatsheet voor OWASP XSS-preventie voor het beveiligen van uw toepassingen tegen XSS. Als u zich nog steeds zorgen maakt, raden we u aan in plaats daarvan de memoryStorage optie te gebruiken.

Gecachete artefacten

MsAL slaat verschillende artefacten op die het gevolg zijn van de API-aanroepen om efficiënte tokenverwerving te facilieren terwijl een goede UX behouden blijft. Hieronder ziet u een overzicht van entiteiten in MSAL-cache:

• Duurzame artefacten (die na de aanvraag blijven bestaan -zie ook: levensduur van tokens)
  • toegangstokens
  • ID-tokens
  • tokens vernieuwen
  • accounts
• Kortstondige artefacten (beperkt tot de levensduur van het verzoek)
  • metagegevens aanvragen (bijvoorbeeld status, nonce, instantie)
  • Fouten
  • interactiestatus
• Telemetrie
  • vorige mislukte aanvraag
  • prestatiegegevens

overschrijving van tijdelijke cachelocatie

Wanneer u MSAL.js gebruikt met de standaardconfiguratie in een scenario waarin de gebruiker wordt omgeleid na een geslaagde verificatie in een nieuw venster of tabblad, wordt de OAuth 2.0-autorisatiecode met PKCE-stroom onderbroken. In dit geval gaat het oorspronkelijke venster of tabblad waar de verificatiestatus (codeverifier en uitdaging) wordt opgeslagen, verloren gaat en mislukt de verificatiestroom.

Als u dit scenario wilt afhandelen, kunt u MSAL configureren voor gebruik localStorage als de cachelocatie door de temporaryCacheLocation configuratie-eigenschap te overschrijven. Hierdoor kunnen de codeverifier en challenge worden opgeslagen in de localStorage van de browser, die behouden blijft in meerdere tabbladen en vensters.

Persistentie van cache tijdens MSAL.js upgrades en terugdraaiacties

Soms moet MSAL.js wijzigingen aanbrengen in de vorm van de artefacten in de cache om nieuwe vereisten, functies of oplossingen voor fouten te ondersteunen. Deze wijzigingen worden zo vaak mogelijk op een achterwaarts compatibele manier aangebracht om ervoor te zorgen dat wanneer een toepassing wordt bijgewerkt naar een nieuwe versie of teruggaat naar een oudere versie, de cache die aanwezig is in de browser van een gebruiker, nog steeds kan worden gebruikt. Dit is echter niet altijd mogelijk en u kunt eindigen in een toestand waarin meerdere kopieën van de cache gelijktijdig bestaan, één die wordt gebruikt door de huidige versie van MSAL.js wordt uitgevoerd en een andere die is geschreven door de versie die vóór de upgrade werd gebruikt. Dit wordt gedaan zodat toepassingen, indien nodig, probleemloos kunnen worden teruggedraaid. In het overgrote deel van de upgrades migreert MSAL.js elke bestaande cache naar de nieuwe indeling voor een naadloze upgrade-ervaring. In zeldzame gevallen, zoals de upgrade van v3 naar v4, is dit mogelijk niet mogelijk vanwege beveiligings- of privacyvereisten, en dit resulteert altijd in een grote versie-bump.

Wanneer er een wijziging in de cache wordt aangebracht die fouten veroorzaakt, wordt de oudere cache standaard vijf dagen bewaard om een terugdraaiactie toe te staan indien nodig. De tijdsduur waarop de oude cache wordt bewaard, kan worden geconfigureerd met behulp van de cacheRetentionDays cacheconfiguratie op PublicClientApplication. Als de cache binnen die tijd niet actief is gebruikt, wordt deze gewist wanneer MSAL.js wordt geïnitialiseerd. Daarnaast kunt u, als u niet verwacht terug te gaan naar een eerdere versie, deze waarde instellen op 0 om aan te geven dat oude cachegegevens altijd onmiddellijk moeten worden verwijderd bij het upgraden naar een nieuwe versie van MSAL.js. Als u echter een langer implementatievenster voor upgrades hebt, kunt u ervoor kiezen om dit in te stellen op een langere waarde.

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

Opmerkingen

• We raden niet aan dat apps bedrijfslogica hebben die afhankelijk is van het directe gebruik van entiteiten in de cache. Gebruik in plaats daarvan de juiste MSAL-API wanneer u tokens moet verkrijgen of accounts wilt ophalen.
• Sleutels die worden gebruikt om het bewijs van bezit (PoP) te versleutelen, worden opgeslagen met behulp van een combinatie van indexedDB-API en geheugenopslag. Raadpleeg het toegangstoken-bewijs van bezit voor meer informatie.

Meer informatie

• Tokens verkrijgen en cachen met behulp van de Microsoft Authentication Library