Erhöhen der Resilienz bei Authentifizierung und Autorisierung in von Ihnen entwickelten Clientanwendungen

Artikel
10/25/2023

Erfahren Sie, wie Sie Resilienz in Clientanwendungen erstellen können, die die Microsoft Identity Platform und Microsoft Entra ID verwenden, um Benutzer anzumelden und Aktionen im Namen dieser Benutzer auszuführen.

Verwenden der Microsoft Authentication Library (MSAL)

Die Microsoft Authentication Library (MSAL) ist Teil der Microsoft Identity Platform. MSAL erwirbt, verwaltet, speichert zwischen und aktualisiert Token; es verwendet bewährte Methoden für Resilienz. MSAL unterstützt Entwickler beim Erstellen sicherer Lösungen.

Weitere Informationen:

MSAL übernimmt das Zwischenspeichern von Token und verwendet ein Muster für den automatischen Tokenabruf. MSAL serialisiert den Tokencache auf Betriebssystemen, die nativ sicheren Speicher wie 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:

Bei der Verwendung von MSAL wird das Zwischenspeichern, das Aktualisieren und der stille Erwerb von Token unterstützt. Sie können einfache Muster verwenden, um die für die Authentifizierung erforderlichen Token abzurufen. Es gibt Unterstützung für viele Sprachen. Suchen Sie nach Codebeispielen für, Microsoft Identity Platform-Codebeispielen.

C#
JavaScript

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

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL kann Token aktualisieren. Wenn die Microsoft Identity Platform ein langlebiges Token ausgibt, kann es Informationen zum Aktualisieren des Tokens an den Client senden (refresh_in). Die App wird ausgeführt, während das alte Token gültig ist, aber es dauert länger, ein anderes Token zu erwerben.

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 Vorgehensweise für Bibliotheken, die sich in der Entwicklung befinden, und verbessern Sie die Resilienz von Apps.

Hier finden Sie die neueste Version und Versionshinweise:

Verwenden von resilienten Mustern für die Verwendung von Token

Wenn Sie MSAL nicht verwenden, sollten Sie resiliente Muster für die Verwendung von Token benutzen. Die MSAL-Bibliothek implementiert bewährte Methoden.

Im Allgemeinen ruft eine Anwendung, die die moderne Authentifizierung verwendet, einen Endpunkt auf, um Token zum Authentifizieren des Benutzers oder zum Autorisieren der Anwendung zum Aufrufen geschützter APIs abzurufen. MSAL übernimmt die Authentifizierung und implementiert Muster, um die Resilienz zu verbessern. Wenn Sie MSAL nicht verwenden, verwenden Sie die Anleitung in diesem Abschnitt für bewährte Methoden. MSAL implementiert und befolgt sonst diese bewährten Methoden automatisch.

Zwischenspeichern von Token

Stellen Sie sicher, dass Apps Token akkurat von der Microsoft Identity Platform zwischenspeichern. Nachdem Ihre App Token empfangen hat, verfügt die HTTP-Antwort mit Token über eine expires_in Eigenschaft, die angibt, wie lange zwischengespeichert werden soll und wann sie wiederverwendet werden soll. Vergewissern Sie sich, dass die Anwendung nicht versucht, ein API-Zugriffstoken zu decodieren.

Diagramm einer App, die die Microsoft Identity Platform über einen Tokencache auf dem Gerät aufruft, 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 Tokenerfassungsfehler, indem die Aufrufe des Tokenerwerbs reduziert werden. Zwischengespeicherte Token verbessern die Anwendungsleistung, da die App das Abrufen 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, vergewissern Sie sich, dass sie nach einem gültigen Zugriff oder einem Aktualisierungstoken sucht. Dies erhöht die Resilienz und Leistung von Apps.

Weitere Informationen:

Stellen Sie sicher, dass der persistente Tokenspeicher über Zugriffssteuerung und Verschlüsselung in Bezug auf den Benutzerbesitzer oder die Prozessidentität verfügt. Auf verschiedenen Betriebssystemen gibt es Features zum Speichern von Anmeldeinformationen.

Automatisches Abrufen von Token

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

Diagramm der Microsoft Identity Platform-Dienste, die dem Abschließen der Benutzerauthentifizierung oder -autorisierung helfen.

Der Erwerb stiller Token beginnt mit einem gültigen Token aus dem Token-Zwischenspeicher. Wenn kein gültiges Token verfügbar ist, versucht die App, mithilfe eines Aktualisierungstokens (falls verfügbar) und des Tokenendpunkts ein Token abzurufen. Wenn keine der Optionen verfügbar ist, ruft die App ein Token mithilfe des prompt=none Parameter auf. Diese Aktion verwendet den Autorisierungsendpunkt, aber für den Benutzer wird keine Benutzeroberfläche angezeigt. Wenn möglich, stellt die Microsoft Identity Platform ein Token für die App ohne Benutzerinteraktion bereit. Wenn keine Methode zu einem Token führt, authentifiziert der Benutzer manuell erneut.

Hinweis

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

Verarbeitung von Antwortcode

In den folgenden Abschnitten erfahren Sie mehr Antwortcodes.

HTTP 429-Antwortcode

Es gibt Fehlerantworten, die sich auf die 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 stellt, 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. Häufig weist eine 429-Antwort darauf hin, dass die Anwendung Token nicht ordnungsgemäß zwischenspeichert und wiederverwendet. Bestätigen Sie, wie Token in der Anwendung zwischengespeichert und wiederverwendet werden.

HTTP 5x-Antwortcode

Wenn eine Anwendung einen HTTP-5x-Antwortcode empfängt, darf die App nicht in eine schnelle Wiederholungsschleife eintreten. 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 eine Wiederholung mit exponentiellem Backoff, wobei der erste Wiederholungsversuch mindestens 5 Sekunden nach der Antwort erfolgen sollte.

Viele Anwendungen und APIs benötigen zum Autorisieren Benutzerinformationen. Verfügbare Methoden haben Vor- und Nachteile.

Token

Identitäts- und Zugriffstoken enthalten Standardansprüche, die Informationen bereitstellen. Wenn die erforderlichen Informationen im Token enthalten sind, sind Tokenansprüche die effizienteste Technik, da dadurch ein weiterer Netzwerkaufruf verhindert wird. Weniger Netzwerkaufrufe entsprechen einer besseren Resilienz.

Weitere Informationen:

Hinweis

Einige Anwendungen rufen zum Abrufen der Ansprüche zum authentifizierten Benutzer den UserInfo-Endpunkt auf. Die Informationen in einem ID-Token sind eine Obermenge der Informationen aus dem UserInfo-Endpunkt. Aktivieren Sie die Verwendung des ID-Tokens für Apps, anstatt den UserInfo-Endpunkt aufzurufen.

Erweitern Sie Standardtokenansprüche mit optionalen Ansprüchen, z. B. Gruppen. Die Option Anwendungsgruppe enthält nur Gruppen, die der Anwendung zugewiesen sind. Mit den Optionen Alle oder Sicherheitsgruppen, die Gruppen aus allen Apps im selben Mandanten enthalten, können Sie dem Token viele Gruppen hinzufügen. 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 über das Portal oder 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, dass mehr APIs aufgerufen werden.

Siehe Hinzufügen von App-Rollen zu Ihrer Anwendung und Empfangen der Rollen im Token

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 geht nicht auf Resilienzprobleme, die durch eine Unfähigkeit Token zu erwerben ausgelöst wird, ein. Fügen Sie optionale Ansprüche für die primären Szenarien der Anwendung hinzu. Wenn die App Informationen zu administrativer Funktionalität erfordert, kann die App diese Informationen, wenn nötig, aufrufen.

Microsoft Graph

Microsoft Graph verfügt über einen einheitlichen API-Endpunkt für den Zugriff auf Microsoft 365-Daten zu Produktivitätsmustern, Identität und Sicherheit. Anwendungen, die Microsoft Graph verwenden, können Microsoft 365-Informationen für die Autorisierung verwenden.

Apps benötigen ein Token für den Zugriff auf Microsoft 365, das resilienter ist als vorherige APIs für Microsoft 365-Komponenten wie Microsoft Exchange oder Microsoft SharePoint, die mehrere Token erforderten.

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

Weitere Informationen finden Sie unter Übersicht über das Microsoft Graph SDK

Erwägen Sie für die Autorisierung die Verwendung von Tokenansprüchen anstatt mehrerer 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 Microsoft Identity Platform und Microsoft Graph angewiesen sind. Wenn Ihre Anwendung jedoch auf Microsoft Graph als Datenebene angewiesen ist, ist Microsoft Graph für die Autorisierung nicht riskanter.

Verwenden der Broker-Authentifizierung auf mobilen Geräten

Bei mobilen Geräten sorgt die Verwendung eines Authentifizierungsbrokers wie Microsoft Authenticator für verbesserte 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 vom Gerät aus auf andere Anwendungen zuzugreifen. Wenn ein PRT Anwendungszugriff anfordert, vertraut Microsoft Entra ID seinen Geräten und MFA-Ansprüchen. Dadurch erhöht sich die Resilienz, indem zusätzliche Schritte zum erneuten Authentifizieren des Geräts vermieden werden. Benutzer werden nicht mit mehreren MFA-Eingabeaufforderungen auf demselben Gerät belastet.

Unter Was ist ein primäres Aktualisierungstoken? finden Sie weitere Informationen

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

MSAL unterstützt die Brokerauthentifizierung. Weitere Informationen:

Fortlaufende Zugriffsevaluierung

Die fortlaufende Zugriffsevaluierung (Continuous Access Evaluation, CAE) erhöht durch langlebige Token Anwendungssicherheit Resilienz. 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. Dies kann bei einigen Ressourcen-APIs die Lebensdauer eines Tokens um bis zu 28 Stunden verlängern, weil Risiken und Richtlinien in Echtzeit ausgewertet werden. MSAL aktualisiert langlebige Token.

Weitere Informationen:

Wenn Sie Ressourcen-APIs entwickeln, wechseln Sie zu openid.net für Shared Signals – A Secure Webhooks Framework.

Freigeben über

Erhöhen der Resilienz bei Authentifizierung und Autorisierung in von Ihnen entwickelten Clientanwendungen