Zwischenspeicherung in MSAL.js

Wenn MSAL ein Token erwirbt, speichert es es für die zukünftige Verwendung zwischen. MSAL verwaltet die Tokenlebensdauern und deren Aktualisierung für Sie. Die acquireTokenSilent() API ruft Zugriffstoken aus dem Cache für ein bestimmtes Konto ab und erneuert sie bei Bedarf.

Cachespeicher

Sie können den Cachespeicherort über das Konfigurationsobjekt konfigurieren, das zum Instanziieren von MSAL verwendet wird:

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

Standardmäßig speichert MSAL die verschiedenen Authentifizierungsartefakte, die sie aus dem IdP im Browserspeicher mithilfe der Webspeicher-API abruft, die von allen modernen Browsern unterstützt wird. Dementsprechend bietet MSAL zwei Methoden für beständigen Speicher: sessionStorage (Standard) und localStorage. Darüber hinaus bietet memoryStorage MSAL eine Option, mit der Sie das Speichern des Caches im Browserspeicher deaktivieren können.

Die Wahl zwischen verschiedenen Speicherorten spiegelt einen Kompromiss zwischen einer besseren Benutzererfahrung im Vergleich zu erhöhter Sicherheit wider. Wie in der obigen Tabelle angegeben, führt der lokale Speicher zu einer bestmöglichen Benutzererfahrung, während der Speicher die beste Sicherheit bietet, da keine vertraulichen Informationen im Browserspeicher gespeichert werden. Weitere Informationen finden Sie im Abschnitt zu Sicherheits - und zwischengespeicherten Artefakten weiter unten.

LocalStorage-Notizen

Ab v4 werden Authentifizierungsartefakte verschlüsselt, wenn Sie den localStorage Cachespeicherort verwenden, es sei denn, der Benutzer wählt während der Anmeldung "Angemeldet bleiben" aus. Der verwendete Verschlüsselungsalgorithmus ist AES-GCM mit HKDF , um den Schlüssel abzuleiten. Der Basisschlüssel wird in einem Sitzungscookies mit dem Titel msal.cache.encryptiongespeichert.

Dieses Cookie wird automatisch entfernt, wenn die Browserinstanz (keine Registerkarte) geschlossen wird und es unmöglich ist, alle Authentifizierungsartefakte nach Beendigung der Sitzung zu entschlüsseln. Diese abgelaufenen Authentifizierungsartefakte werden beim nächsten Initialisieren von MSAL entfernt, und der Benutzer muss möglicherweise erneut authentifizieren. Der localStorage Speicherort bietet weiterhin tabübergreifende Cache-Persistenz für alle Benutzer, bleibt jedoch nur für Benutzer über Browsersitzungen hinweg bestehen, die „Angemeldet bleiben“ (KMSI) ausgewählt haben.

Cookiespeicherung

MSAL Browser kann so konfiguriert werden, dass Cookies zum Speichern temporärer Authentifizierungsartefakte verwendet werden. Mit dieser Option können Sie Browser unterstützen, die den lokalen/Sitzungsspeicher während umleitungsbasierter Anmeldeflüsse löschen können (z. B. Internet Explorer, Firefox im privaten Modus). Beachten Sie, dass Token, wenn diese Option ausgewählt wird, weiterhin im Browser oder im Speicher gespeichert sind. Weitere Informationen finden Sie in der Konfiguration .

Security

Wir betrachten Session-/Local-Storage als sicher, solange Ihre Anwendung keine Cross-Site-Scripting-(XSS-) und verwandten Schwachstellen aufweist. Bitte lesen Sie das OWASP XSS Prevention Cheat Sheet zum Sichern Ihrer Anwendungen gegen XSS. Wenn Sie immer noch besorgt sind, empfehlen wir stattdessen die Verwendung der memoryStorage Option.

Zwischengespeicherte Artefakte

Um eine effiziente Tokenakquise zu vermitteln und gleichzeitig eine gute UX zu erhalten, speichert MSAL verschiedene Artefakte zwischen, die sich aus ihren API-Aufrufen ergeben. Nachfolgend finden Sie eine Zusammenfassung der Entitäten im MSAL-Cache:

• Dauerhafte Artefakte (die über die Anfrage hinaus bestehen – siehe auch: Token-Lebensdauern)
  • Zugriffstoken
  • ID-Tokenಗಳು
  • Aktualisierungstoken
  • Konten
• Temporäre Artefakte (beschränkt auf die Lebensdauer der Anfrage)
  • Anforderungsmetadaten (z. B. Status, Nonce, Autorität)
  • Irrtümer
  • Interaktionsstatus
• Telemetrie
  • Vorherige fehlgeschlagene Anforderung
  • Leistungsdaten

temporaryCacheLocation-Außerkraftsetzung

Wenn Sie MSAL.js mit der Standardkonfiguration in einem Szenario verwenden, in dem der Benutzer nach erfolgreicher Authentifizierung in einem neuen Fenster oder einer neuen Registerkarte umgeleitet wird, wird der OAuth 2.0-Autorisierungscode mit PKCE-Fluss unterbrochen. In diesem Fall gehen das ursprüngliche Fenster oder die ursprüngliche Registerkarte, in dem der Authentifizierungsstatus (Codeprüfer und Herausforderung) gespeichert ist, verloren, und der Authentifizierungsfluss schlägt fehl.

Um dieses Szenario zu umgehen, können Sie MSAL so konfigurieren, dass localStorage als Cachespeicherort verwendet wird, indem Sie die Konfigurationseigenschaft temporaryCacheLocation überschreiben. Dadurch können der Code-Verifier und die Challenge im localStorage des Browsers gespeichert werden, was über mehrere Registerkarten und Fenster hinweg erhalten bleibt.

Cachepersistenz während MSAL.js Upgrades und Rollbacks

Gelegentlich müssen MSAL.js Änderungen an der Form der zwischengespeicherten Artefakte vornehmen, um neue Anforderungen, Features oder Fehlerbehebungen zu unterstützen. So oft wie möglich werden diese Änderungen abwärtskompatibel vorgenommen, um sicherzustellen, dass der Cache, der im Browser eines Benutzers vorhanden ist, weiterhin verwendet werden kann, wenn eine Anwendung auf eine neue Version aktualisiert oder auf eine ältere Version zurückgesetzt wird. Dies ist jedoch nicht immer möglich, und Sie können in einem Zustand enden, in dem mehrere Kopien des Caches gleichzeitig vorhanden sind, eine, die von der aktuellen Version von MSAL.js ausgeführt wird und eine andere, die von der vor dem Upgrade verwendeten Version geschrieben wurde. Dies geschieht, damit Anwendungen bei Bedarf ein ordnungsgemäßes Rollback durchführen können. In den meisten Upgrades migriert MSAL.js alle vorhandenen Caches in das neue Format, um ein nahtloses Upgrade zu ermöglichen. In seltenen Fällen, wie etwa bei einem Upgrade von v3 auf v4, ist dies aufgrund von Sicherheits- oder Datenschutzanforderungen möglicherweise nicht möglich, und dies führt immer zu einer Erhöhung der Hauptversion.

Wenn eine Änderung des zwischengespeicherten Caches vorgenommen wird, wird der ältere Cache standardmäßig 5 Tage lang aufbewahrt, um bei Bedarf ein Rollback zuzulassen. Wie lange alter Cache gespeichert wird, kann mithilfe der cacheRetentionDays Cachekonfiguration auf PublicClientApplication festgelegt werden. Wenn der Cache innerhalb dieses Zeitraums nicht aktiv verwendet wurde, wird er gelöscht, wenn MSAL.js das nächste Mal initialisiert wird. Wenn Sie nicht davon ausgehen, dass ein Rollback ausgeführt werden muss, können Sie diesen Wert 0 so festlegen, dass der alte Cache beim Upgrade auf eine neue Version von MSAL.jsimmer sofort entfernt werden soll. Wenn Sie dagegen ein längeres Rolloutfenster für Upgrades haben, können Sie dies auf einen längeren Wert festlegen.

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

Bemerkungen

• Es wird nicht empfohlen, dass Apps Geschäftslogik verwenden, die von der direkten Verwendung von Entitäten im Cache abhängig sind. Verwenden Sie stattdessen die entsprechende MSAL-API, wenn Sie Token abrufen oder Konten abrufen müssen.
• Schlüssel, die zum Verschlüsseln des Besitznachweises (PoP)-Token verwendet werden, werden mithilfe einer Kombination aus IndexedDB-API und Speicher gespeichert. Weitere Informationen finden Sie unter access-token-proof-of-possession.

Weitere Informationen

• Abrufen und Zwischenspeichern von Token mithilfe der Microsoft Authentication Library (MSAL)