Freigeben über

Erhöhen der Resilienz der Authentifizierung und Autorisierung in Clientanwendungen, die Sie entwickeln

Erfahren Sie, wie Sie Resilienz in Clientanwendungen erstellen, die die Microsoft Identity Platform und die Microsoft Entra-ID zum Anmelden von Benutzern verwenden, und Aktionen im Namen dieser Benutzer ausführen.

Verwenden der Microsoft Authentication Library (MSAL)

Die Microsoft Authentication Library (MSAL) ist Teil der Microsoft Identity Platform. MSAL übernimmt Token, verwaltet, zwischenspeichert und aktualisiert Token; es verwendet bewährte Methoden zur Resilienz. MSAL hilft Entwicklern beim Erstellen sicherer Lösungen.

Weitere Informationen:

MSAL speichert Token und verwendet ein stilles Tokenakquisitionsmuster. MSAL serialisiert den Tokencache auf Betriebssystemen, die nativen sicheren Speicher wie die Universelle Windows-Plattform (UWP), iOS und Android bereitstellen. Passen Sie das Serialisierungsverhalten an, wenn Sie Folgendes verwenden:

  • Microsoft.Identity.Web
  • MSAL.NET
  • MSAL für Java
  • MSAL für Python

Weitere Informationen:

Wenn Sie MSAL verwenden, werden das Zwischenspeichern und Aktualisieren von Tokens sowie der lautlose Erwerb unterstützt. Verwenden Sie einfache Muster, um die Token für die Authentifizierung abzurufen. Es gibt Unterstützung für viele Sprachen. Codebeispiele finden Sie auf Microsoft Identity Platform.

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

MSAL kann Token aktualisieren. Wenn die Microsoft Identity Platform ein langlebiges Token ausgibt, kann es Informationen an den Client senden, um das Token zu aktualisieren (refresh_in). Die App wird ausgeführt, während das alte Token gültig ist, aber für einen anderen Tokenerwerb dauert es länger.

MSAL-Releases

Wir empfehlen Entwicklern, einen Prozess zur Verwendung der neuesten MSAL-Version zu erstellen, da die Authentifizierung Teil der App-Sicherheit ist. Verwenden Sie diese Methode für Bibliotheken in der Entwicklung und verbessern Sie die App-Resilienz.

Hier finden Sie die neuesten Versions- und Versionshinweise:

Verwenden von resilienten Mustern für die Verwendung von Token

Wenn Sie MSAL nicht verwenden, verwenden Sie belastbare Muster für die Tokenverwaltung. Die MSAL-Bibliothek implementiert bewährte Methoden.

Im Allgemeinen rufen Anwendungen, die moderne Authentifizierung verwenden, einen Endpunkt auf, um Token abzurufen, die den Benutzer authentifizieren oder die Anwendung zum Aufrufen geschützter APIs autorisieren. MSAL verarbeitet die Authentifizierung und implementiert Muster zur Verbesserung der Resilienz. Wenn Sie MSAL nicht verwenden, verwenden Sie die Anleitungen in diesem Abschnitt für bewährte Methoden. Andernfalls implementiert MSAL automatisch bewährte Methoden.

Das Sicherungsauthentifizierungssystem von Microsoft Entra ID bietet Widerstandsfähigkeit für Anwendungen, die unterstützte Protokolle und Abläufe verwenden. Weitere Informationen zu den Anwendungsanforderungen, die von der Sicherungsauthentifizierung profitieren sollen, finden Sie unter Anwendungsanforderungen für das Sicherungsauthentifizierungssystem.

Zwischenspeichern von Token

Stellen Sie sicher, dass Apps Token genau von der Microsoft Identity Platform zwischenspeichern. Nachdem Ihre App Token empfängt, weist die HTTP-Antwort mit Token eine expires_in Eigenschaft auf, die die Zwischenspeicherdauer angibt und wann sie wiederverwendet werden soll. Bestätigen Sie, dass die Anwendung nicht versucht, ein API-Zugriffstoken zu decodieren.

Diagramm einer App, die microsoft Identity Platform aufruft, über einen Tokencache auf dem Gerät, auf dem die Anwendung ausgeführt wird.

Zwischengespeicherte Token verhindern unnötigen Datenverkehr zwischen einer App und der Microsoft Identity Platform. In diesem Szenario ist die App weniger anfällig für Tokenakquisitionsfehler, indem Tokenerwerbsaufrufe reduziert werden. Zwischengespeicherte Token verbessern die Anwendungsleistung, da die App den Erwerb von Token weniger häufig blockiert. Benutzer bleiben für die Tokenlebensdauer bei Ihrer Anwendung angemeldet.

Serialisieren und Beibehalten von Token

Stellen Sie sicher, dass Apps ihren Tokencache sicher serialisieren, um die Token zwischen App-Instanzen beizubehalten. Token während ihrer Lebensdauer wiederverwenden. Aktualisierungstoken und Zugriffstoken werden für viele Stunden ausgegeben. Während dieser Zeit können Benutzer Ihre Anwendung mehrmals starten. Wenn eine App gestartet wird, bestätigen Sie, dass sie nach gültigem Zugriff oder nach einem Aktualisierungstoken sucht. Dies erhöht die Resilienz und Leistung der App.

Weitere Informationen:

Stellen Sie sicher, dass der permanente Tokenspeicher über Zugriffssteuerung und Verschlüsselung im Verhältnis zum Benutzerbesitzer oder zur Prozessidentität verfügt. Auf verschiedenen Betriebssystemen gibt es Speicherfunktionen für Anmeldeinformationen.

Automatisches Abrufen von Token

Die Authentifizierung eines Benutzers oder das Abrufen der Autorisierung zum Aufrufen einer API umfasst mehrere Schritte in der Microsoft Identity Platform. Benutzer, die sich zum ersten Mal anmelden, geben Anmeldeinformationen ein und führen eine mehrstufige Authentifizierung aus. Jeder Schritt wirkt sich auf die Ressource aus, die den Dienst bereitstellt. Die beste Benutzererfahrung mit den geringsten Abhängigkeiten ist der stille Tokenerwerb.

Diagramm der Microsoft Identity Platform-Dienste, die bei der Durchführung der Benutzerauthentifizierung oder Autorisierung helfen.

Stiller Tokenerwerb beginnt mit einem gültigen Token aus dem App-Tokencache. Wenn kein gültiges Token vorhanden ist, versucht die App, ein Token mithilfe eines verfügbaren Aktualisierungstokens und des Tokenendpunkts abzurufen. Wenn keine der beiden Optionen verfügbar ist, erwirbt die App ein Token mit dem prompt=none Parameter. Diese Aktion verwendet den Autorisierungsendpunkt, aber für den Benutzer wird keine Benutzeroberfläche angezeigt. Wenn möglich, stellt die Microsoft Identity Platform eine Token für die App ohne Benutzerinteraktion bereit. Wenn keine Methode zu einem Token führt, wird der Benutzer manuell erneut authentifiziert.

Hinweis

Stellen Sie im Allgemeinen sicher, dass Apps keine Eingabeaufforderungen wie "Anmeldung" und "Zustimmung" verwenden. Diese Aufforderungen erzwingen die Benutzerinteraktion, wenn keine Interaktion erforderlich ist.

Behandlung von Antwortcode

In den folgenden Abschnitten erfahren Sie mehr über Antwortcodes.

HTTP 429-Antwortcode

Es gibt Fehlerantworten, die sich auf resilienz auswirken. Wenn Ihre Anwendung einen HTTP-Antwortcode 429 (zu viele Anforderungen) empfängt, drosselt Microsoft Identity Ihre Anforderungen. Wenn eine App zu viele Anforderungen vorgibt, wird sie gedrosselt, um zu verhindern, dass die App Token empfängt. Lassen Sie nicht zu, dass eine App das Aufrufen von Token versucht, bevor die Antwortfeldzeit Wiederholung danach abgeschlossen ist. Oft zeigt eine 429-Antwort an, dass die Anwendung Token nicht ordnungsgemäß zwischenspeichert und wiederverwendet. Überprüfen Sie, wie Token zwischengespeichert und in der Anwendung wiederverwendet werden.

HTTP 5x-Antwortcode

Wenn eine Anwendung einen HTTP 5x-Antwortcode empfängt, darf die App keine schnelle Wiederholungsschleife eingeben. Verwenden Sie dieselbe Behandlung für eine 429-Antwort. 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.

Wenn bei einer Anforderung ein Zeitüberschreitungsausfall erfolgt, wird von sofortigen Wiederholungen abgeraten. Implementieren Sie einen exponentiellen Backoff-Wiederholungsversuch, wobei der erste Versuch mindestens 5 Sekunden nach der Antwort erfolgt.

Viele Anwendungen und APIs benötigen Benutzerinformationen, um sie zu autorisieren. Verfügbare Methoden haben Vor- und Nachteile.

Tokenen

Identitätstoken (ID) und Zugriffstoken verfügen über Standardansprüche, die Informationen bereitstellen. Wenn erforderliche Informationen im Token vorhanden sind, handelt es sich bei der effizientesten Technik um Tokenansprüche, da dadurch ein anderer Netzwerkaufruf verhindert wird. Weniger Netzwerkaufrufe entsprechen einer besseren Resilienz.

Weitere Informationen:

Hinweis

Einige Anwendungen rufen den UserInfo-Endpunkt auf, um Ansprüche über den authentifizierten Benutzer abzurufen. Die Informationen im ID-Token sind eine Obermenge von Informationen vom UserInfo-Endpunkt. Ermöglichen Sie Apps, das ID-Token zu verwenden, anstatt den UserInfo-Endpunkt aufzurufen.

Erweitern Sie die Standardtoken-Ansprüche durch optionale Ansprüche, wie zum Beispiel Gruppen. Die Option "Anwendungsgruppe " enthält Gruppen, die der Anwendung zugewiesen sind. Die Optionen "Alle " oder "Sicherheitsgruppen " enthalten Gruppen aus Apps im selben Mandanten, die dem Token Gruppen hinzufügen können. Evaluieren Sie die Auswirkung, da sie die Effizienz der Anforderung von Gruppem im Token, ausgelöst durch eine Token-Überfrachtung, negieren kann und mehr Aufrufe für die Gruppen erforderlich macht.

Weitere Informationen:

Es wird empfohlen, App-Rollen zu verwenden und einzubeziehen, die Kunden mithilfe des Portals oder der APIs verwalten. Weisen Sie Benutzern und Gruppen Rollen zu, um den Zugriff zu steuern. Wenn ein Token ausgestellt wird, befinden sich die zugewiesenen Rollen im Tokenrollenanspruch. Von einem Token abgeleitete Informationen verhindern mehr APIs-Aufrufe.

Siehe: App-Rollen zu Ihrer Anwendung hinzufügen und diese im Token erhalten

Fügen Sie Ansprüche basierend auf Mandanteninformationen hinzu. Beispielsweise verfügt eine Erweiterung über eine unternehmensspezifische Benutzer-ID.

Das Hinzufügen von Informationen aus dem Verzeichnis zu einem Token ist effizient und erhöht die Resilienz, indem Abhängigkeiten reduziert werden. Es werden keine Resilienzprobleme behoben, da ein Token nicht abgerufen werden kann. Fügen Sie optionale Ansprüche für die primären Szenarien der Anwendung hinzu. Wenn die App Informationen für administrative Funktionen benötigt, kann die Anwendung diese Informationen nach Bedarf abrufen.

Microsoft Graph

Microsoft Graph verfügt über einen einheitlichen API-Endpunkt, um auf Microsoft 365-Daten über Produktivitätsmuster, Identität und Sicherheit zuzugreifen. Anwendungen, die Microsoft Graph verwenden, können Microsoft 365-Informationen zur Autorisierung verwenden.

Apps erfordern ein Token für den Zugriff auf Microsoft 365, was stabiler als vorherige APIs für Microsoft 365-Komponenten wie Microsoft Exchange oder Microsoft SharePoint ist, die mehrere Token erfordern.

Wenn Sie Microsoft Graph-APIs verwenden, verwenden Sie ein Microsoft Graph-SDK, das das Erstellen robuster Anwendungen vereinfacht, die auf Microsoft Graph zugreifen.

Übersicht über das Microsoft Graph SDK

Erwägen Sie für die Autorisierung die Verwendung von Tokenansprüchen anstelle einiger Microsoft Graph-Aufrufe. Fordern Sie Gruppen, App-Rollen und optionale Ansprüche in Token an. Microsoft Graph für die Autorisierung erfordert mehr Netzwerkaufrufe, die auf der Microsoft Identity Platform und Microsoft Graph basieren. Wenn Ihre Anwendung jedoch Microsoft Graph als Datenebene nutzt, ist Microsoft Graph für die Autorisierung kein größeres Risiko.

Verwenden der Brokerauthentifizierung auf mobilen Geräten

Auf mobilen Geräten verbessert ein Authentifizierungsbroker wie Microsoft Authenticator die Resilienz. Der Authentifizierungsbroker verwendet ein primäres Aktualisierungstoken (PRT) mit Ansprüchen über den Benutzer und das Gerät. Verwenden Sie PRT für Authentifizierungstoken, um auf andere Anwendungen vom Gerät zuzugreifen. Wenn ein PRT den Anwendungszugriff anfordert, vertraut Microsoft Entra ID seinem Gerät und seinen MFA-Ansprüchen. Dadurch wird die Resilienz erhöht, indem Die Schritte zur Authentifizierung des Geräts reduziert werden. Benutzer werden nicht mit mehreren MFA-Aufforderungen auf demselben Gerät herausgefordert.

Siehe: Was ist ein primäres Aktualisierungstoken?

Diagramm einer App, die Microsoft Identity Platform aufruft, über einen Tokencache und Tokenspeicher sowie Authentifizierungsbroker auf dem Gerät, auf dem die Anwendung ausgeführt wird.

MSAL unterstützt die Brokerauthentifizierung. Weitere Informationen:

Fortlaufende Zugriffsevaluierung

Die Kontinuierliche Zugriffsauswertung (Continuous Access Evaluation, CAE) erhöht die Anwendungssicherheit und -resilienz mit langlebigen Token. Statt Token mit kurzer Gültigkeitsdauer zu verwenden, können Sie bei der fortlaufenden Zugriffsevaluierung (CAE) ein Zugriffstoken auf Basis von kritischen Ereignissen und Richtlinienauswertung widerrufen. Bei einigen Ressourcen-APIs erhöht caE die Tokenlebensdauer bis zu 28 Stunden, da Risiken und Richtlinien in Echtzeit ausgewertet werden. MSAL aktualisiert langlebige Token.

Weitere Informationen:

Wenn Sie Ressourcen-APIs entwickeln, wechseln Sie zu openid.netShared Signals – ein sicheres Webhooks-Framework.

Nächste Schritte