Erhöhen der Resilienz von Authentifizierung und Autorisierung in Daemon-Anwendungen, die Sie entwickeln
Erfahren Sie, wie die Sie Microsoft Identity Platform und Microsoft Entra ID nutzen können, um die Resilienz von Daemon-Anwendungen zu erhöhen. Hier finden Sie Informationen zu Hintergrundprozessen, Diensten, Server-zu-Server-Apps und Anwendungen ohne Benutzer.
Siehe Was ist die Microsoft Identity Platform?
Das folgende Diagramm veranschaulicht eine Daemon-Anwendung, die Microsoft Identity Platform aufruft.
Verwaltete Identitäten für Azure-Ressourcen
Wenn Sie Daemon-Apps in Microsoft Azure erstellen, verwenden Sie verwaltete Identitäten für Azure-Ressourcen, die Geheimnisse und Anmeldeinformationen verarbeiten. Die Funktion verbessert die Resilienz, indem sie den Zertifikatablauf, Rotationsfehler oder Vertrauensstellungen behandelt.
Lesen Sie dazu Was sind verwaltete Identitäten für Azure-Ressourcen?
Verwaltete Identitäten verwenden langlebige Zugriffstoken und Informationen von der Microsoft Identity Platform, um neue Token abzurufen, bevor Token ablaufen. Ihre App wird ausgeführt, während Sie neue Token abrufen.
Verwaltete Identitäten verwenden regionale Endpunkte, mit denen Out-of-Region-Fehler verhindert werden, indem Dienstabhängigkeiten konsolidiert werden. Regionale Endpunkte tragen dazu bei, den Datenverkehr in einem geografischen Gebiet zu halten. Wenn sich Ihre Azure-Ressource beispielsweise in WestUS2 befindet, bleibt der Datenverkehr auch in WestUS2.
Microsoft Authentication Library (MSAL)
Wenn Sie Daemon-Apps entwickeln und keine verwalteten Identitäten verwenden, verwenden Sie die Microsoft Authentication Library (MSAL) für die Authentifizierung und Autorisierung. MSAL vereinfacht die Bereitstellung von Clientanmeldeinformationen. Beispielsweise muss Ihre Anwendung keine JSON-Webtokenassertionen mit zertifikatbasierten Anmeldeinformationen erstellen und signieren.
Siehe Übersicht über die Microsoft-Authentifizierungsbibliothek (MSAL).
Microsoft.Identity.Web für .NET-Entwickler
Wenn Sie Daemon-Apps auf ASP.NET Core entwickeln, verwenden Sie die Microsoft.Identity.Web-Bibliothek, um die Autorisierung zu vereinfachen. Sie umfasst verteilte Tokencachestrategien für verteilte Apps, die in mehreren Regionen ausgeführt werden.
Weitere Informationen:
Zwischenspeichern und Speichern von Token
Wenn Sie MSAL nicht für die Authentifizierung und Autorisierung verwenden, gibt es bewährte Methoden für das Zwischenspeichern und Speichern von Token. MSAL implementiert und befolgt diese bewährten Methoden.
Eine Anwendung ruft Token von einem Identitätsanbieter (IdP) ab, um die Anwendung für das Aufrufen geschützter APIs zu autorisieren. Wenn Ihre App Token empfängt, enthält die Antwort mit den Token die Eigenschaft „expires\_in“, die die Anwendung informiert, wie lange das Token zwischengespeichert und wiederverwendet werden soll. Stellen Sie sicher, dass Anwendungen die expires\_in -Eigenschaft verwenden, um die Lebensdauer des Tokens zu bestimmen. Vergewissern Sie sich, dass die Anwendung nicht versucht, ein API-Zugriffstoken zu decodieren. Die Verwendung des zwischengespeicherten Tokens verhindert unnötigen Datenverkehr zwischen einer App und Microsoft Identity Platform. Benutzer sind für die Lebensdauer des Tokens bei Ihrer Anwendung angemeldet.
HTTP 429- und 5xx-Fehlercodes
Verwenden Sie die folgenden Abschnitte, um mehr über HTTP 429- und 5xx-Fehlercodes zu erfahren.
HTTP 429
Es gibt HTTP-Fehler, die sich auf die Resilienz auswirken. Wenn Ihre Anwendung den HTTP 429-Fehlercode „Zu viele Anforderungen“ empfängt, drosselt Microsoft Identity Platform Ihre Anforderungen, wodurch verhindert wird, dass Ihre App Token empfängt. Stellen Sie sicher, dass Ihre Apps erst versuchen, ein Token abzurufen, wenn die Zeit im Feld Retry-After abläuft. Der 429-Fehler weist häufig darauf hin, dass die Anwendung Token nicht ordnungsgemäß zwischenspeichert und wiederverwendet.
HTTP 5xx
Wenn eine Anwendung einen HTTP 5x-Fehlercode empfängt, darf die App nicht in eine schnelle Wiederholungsschleife eintreten. Stellen Sie sicher, dass Anwendungen warten, bis das Feld Retry-After abläuft. Wenn von der Antwort kein „Retry-After“-Header bereitgestellt wird, verwenden Sie eine Wiederholung mit exponentiellem Backoff für die erste Wiederholung mindestens 5 Sekunden nach der Antwort.
Stellen Sie sicher, dass Anwendungen nicht sofort Wiederholungsversuche ausführen, wenn für eine Anforderung ein Timeout auftritt. Verwenden Sie die zuvor zitierte Wiederholung mit exponentiellem Backoff.