Überlegungen zur hohen Verfügbarkeit in MSAL.NET

Informationen zum Clientanmeldeinformations-Flow finden Sie zunächst in der Dokumentation zu Clientanmeldeinformationen.

Verwenden einer API auf höherer Ebene

MSAL ist eine API auf niedrigerer Ebene. Wenn Sie eine neue App entwickeln, sollten Sie die übergeordnete Lösung Microsoft.Identitity.Web in Betracht ziehen, die eine sofort einsatzbereite Integration mit ASP.NET Core und ASP.NET Classic bietet.

Verwenden Sie die neueste MSAL

Verwenden Sie das neueste MSAL, um die Fehlerbehebungen und Leistungsverbesserungen zu erhalten. Semantische Versionsverwaltungsregeln werden befolgt.

Sie möchten auch überprüfen, ob Sie Microsoft Identity Web, eine Bibliothek auf höherer Ebene für Web-Apps und Web-APIs verwenden sollten, was für Sie viele der unten beschriebenen Aktionen ausführt. Siehe Auswählen einer Version von MSAL.NET, die eine Entscheidungsstruktur vorschlägt, um je nach Plattform und Einschränkungen die beste Lösung auszuwählen.

Verwenden des Tokencaches

Standardverhalten: MSAL speichert die Token im Arbeitsspeicher zwischen. Jede ConfidentialClientApplication Instanz verfügt über einen eigenen internen Tokencache. Der Speichercache kann z. B. verloren gehen, wenn die Objektinstanz verworfen oder die gesamte Anwendung beendet wird.

Empfehlung: Alle Apps sollten ihre Tokencaches beibehalten. Web-Apps und Web-APIs sollten einen L1/L2-Tokencache verwenden, bei dem L2 ein verteilter Speicher wie Redis für die Skalierung ist. Desktop-Apps sollten eine ordnungsgemäße Serialisierungsstrategie für den Tokencache verwenden.

Standardverhalten: MSAL verwaltet einen sekundären ADAL-Tokencache für Migrationsszenarien zwischen ADAL und MSAL. ADAL-Cachevorgänge sind sehr langsam. Empfehlung: Deaktivieren Sie den ADAL-Cache, wenn Sie nicht für die Migration von ADAL interessiert sind. Dies wird zu einer BIG Leistungsverbesserung führen – siehe Leistungsmessungen hier.

Fügen Sie WithLegacyCacheCompatibility(false) beim Erstellen Ihrer App hinzu, um die ADAL-Zwischenspeicherung zu deaktivieren.

Überwachung für MSAL-Vorgänge hinzufügen

MSAL macht wichtige Metriken als Teil des AuthenticationResult.AuthenticationResultMetadata-Objekts verfügbar:

Protokollierung

Abhören von Warning und Error Ebenennachrichten, die aus MSAL-Protokollen stammen. Dies können stille Fehler oder dringende Empfehlungen sein, eine andere Konfiguration zu verwenden. Es wird nicht empfohlen, Verbose Logging in der Produktion zu aktivieren, da dadurch viele Meldungen erzeugt werden und die Performance beeinträchtigt wird.

Details zur Protokollierung finden Sie im Handbuch "Protokollierung in MSAL.NET".

Richtlinie für Wiederholungsversuche

Standardverhalten: MSAL wiederholt einmal fehlgeschlagene 5xx-Anforderungen.

Empfehlung:

• Lesen Sie unsere Dokumentation zur Wiederholungsrichtlinie zum Erstellen einer Wiederholungsrichtlinie mit Polly.

Ein vertraulicher Client pro Sitzung

Es wird empfohlen, für jede Sitzung eine neue ConfidentialClientApplication zu verwenden und auf die gleiche Weise zu serialisieren – einen Tokencache pro Sitzung. Dies skaliert gut und erhöht auch die Sicherheit. Die offiziellen Beispiele zeigen, wie das geht. Sie müssen die Tokenzwischenspeicherung konfigurieren , damit dies ordnungsgemäß funktioniert.

HttpClient

Standardverhalten: MSAL-created HttpClient ist für Websites/Web-API nicht gut skaliert, wo wir empfehlen, für jede Benutzersitzung ein ClientApplication Objekt zu verwenden.

Empfehlung: Stellen Sie Ihre eigene skalierbare HttpClientFactory bereit. Unter .NET Core empfehlen wir, System.Net.Http.IHttpClientFactory zu injizieren. Dies wird in der Bereitstellung Ihres eigenen HttpClient, der Unterstützung von HTTP-Proxys und der Anpassung von Benutzer-Agent-Headern und in der dokumentation .NET ausführlicher beschrieben.

Proaktive Tokenverlängerung

Zielsetzung

Erhöhen Sie die Anwendungsverfügbarkeit, indem Sie längerlebige Zugriffstoken ausgeben und sicherstellen, dass sie vor dem Ablaufdatum aktualisiert werden.

Status quo

Standardmäßig gibt Microsoft Entra ID Zugriffstoken mit einer Ablaufzeit von 1 Stunde aus. Wenn ein Microsoft Entra Ausfall auftritt, wenn ein Token aktualisiert werden muss, schlägt MSAL fehl. Der Fehler wird an die aufrufende Anwendung weitergegeben und wirkt sich auf die Verfügbarkeit aus.

Prozess

Um die Verfügbarkeit zu verbessern, versucht MSAL sicherzustellen, dass eine App immer über frische nicht abgelaufene Token verfügt. Microsoft Entra Ausfälle dauern nur selten mehr als ein paar Stunden. Wenn MSAL also garantieren kann, dass ein Token immer mindestens ein paar Stunden Verfügbarkeit übrig hat, wird die Anwendung nicht von dem Microsoft Entra Ausfall betroffen sein.

Um Token mit langer Gültigkeitsdauer zu erhalten, müssen Sie Ihren Mandanten konfigurieren (Hinweis: Interne Microsoft-Mandanten sind bereits konfiguriert). Für client_credentials (Dienst 2) reicht dies aus. Für Benutzeranmeldeinformationen müssen Sie auch caE – /azure/active-directory/conditional-access/concept-continuous-access-evaluation konfigurieren.

Wenn Microsoft Entra ID ein langlebiges Token zurückgibt, enthält es ein refresh_in-Feld. Er wird in der Regel auf die Hälfte der Ablaufzeit des Access-Tokens festgelegt.

Hinweis: Ab MSAL 4.37.0 können Sie diesen Wert durch Überprüfen des AuthenticationResult.AuthenticationResultMetadata.RefreshOn ermitteln.

Darüber hinaus können Sie eine Tokenlebensdauer von mehr als der standard 1 Stunde konfigurieren, wie in konfigurierbaren Tokenlebensdauern im Microsoft Identity Platform (Vorschau) beschrieben.

Immer wenn Sie Anforderungen für dasselbe Token stellen, d. h. wenn MSAL ein Token aus dem Cache bereitstellen kann, überprüft MSAL automatisch den refresh_in Wert. Wenn sie abgelaufen ist, gibt MSAL eine Tokenanforderung an Microsoft Entra ID im Hintergrund aus, gibt jedoch das vorhandene, gültige Token an die Anwendung zurück. Im unwahrscheinlichen Fall, dass die Hintergrundaktualisierung fehlschlägt (z. B. Microsoft Entra Ausfall), ist die App nicht betroffen.

Zertifikatrotation

Zertifikate für die vertrauliche Client-App müssen aus Sicherheitsgründen gedreht werden (verwenden Sie keine geheimen Schlüssel in Prod.!). Es gibt mehrere Möglichkeiten für den Umgang mit der Zertifikatsrotation, in der Reihenfolge von der am meisten bevorzugten bis zur am wenigsten bevorzugten:

1. Verwenden der verwalteten Identität

Mit verwalteter Identität wird Vertrauen dadurch hergestellt, dass Ihre App in Azure gehostet wird. Es gibt keine geheimen Schlüssel, die verwaltet werden müssen, und keine Zertifikate, die gedreht werden sollen.

2. Verwenden der Microsoft.Identity.Web Zertifikatbehandlungslogik

Verwenden Sie in Web-Apps und Web-APIs Microsoft.Identity.Web, eine API auf höherer Ebene über MSAL. Es übernimmt die Zertifikatsrotation, wenn das Zertifikat in Azure Key Vault gespeichert ist, sowie den Fall einer verwalteten Identität.

Weitere Informationen finden Sie in den Zertifikaten in Microsoft. Identity.Web guide.

Dies ist die bevorzugte Lösung für nicht Microsoft interne Dienste mit ASP.NET Core.

3. (Nur Microsoft-intern) Verwenden Sie Zertifikate mit Subjektname/Aussteller.

Mit diesem Mechanismus können Microsoft Entra ID ein Zertifikat basierend auf SN/I anstelle eines Fingerabdrucks (x5t) identifizieren. Es handelt sich um eine Stop-Gap-Lösung; es gibt keine Pläne, sie für Nicht-Microsoft Anwendungen verfügbar zu machen.

Dies ist die bevorzugte Lösung für Microsoft internen Dienste, die keine verwaltete Identität verwenden können.