Freigeben über

Unterstützung des Authentifizierungsflows in der MSAL

  • Artikel

Die Microsoft Authentication Library (MSAL) unterstützt mehrere Autorisierungszuweisungen und zugehörige Tokenflows zur Verwendung durch verschiedene Anwendungstypen und -Szenarien.

Authentifizierungsfluss ermöglicht Unterstützte Anwendungstypen
Autorisierungscode Benutzer melden sich an und greifen im Namen des Benutzers auf Web-APIs zu. Desktop
Mobile
Single-Page-Webanwendung (SPA) (erfordert PKCE)
Web
Clientanmeldeinformationen Zugriff auf Web-APIs mithilfe der Identität der Anwendung selbst. Wird in der Regel für die Kommunikation zwischen Servern und automatisierten Skripts verwendet, die keine Benutzerinteraktion erfordern. Daemon
Gerätecode Benutzer melden sich an und greifen im Namen des Benutzers auf Web-APIs auf Geräten mit Eingabebeschränkungen wie Smart-TVs und IoT-Geräte zu. Wird auch von CLI-Anwendungen (Befehlszeilenschnittstelle) verwendet. Desktop- und Mobilgeräte
Implizite Gewährung Benutzer melden sich an und greifen im Namen des Benutzers auf Web-APIs zu. Diesen Flow nicht verwenden - stattdessen Autorisierungscode mit PKCE verwenden. * Single-Page-App (SPA)
* Web
Im Auftrag von (OBO, On-Behalf-Of) Zugriff einer vorgelagerten Web-API auf eine nachgelagerte Web-API im Namen des Benutzers. Die Identität des Benutzers und die delegierten Berechtigungen werden von der vorgelagerten API an die nachgelagerte API übergeben. Web-API
Benutzername/Kennwort (ROPC) Ermöglicht es einer Anwendung, den Benutzer durch die direkte Verarbeitung seines Kennworts anzumelden. Diesen Flow nicht verwenden. Desktop- und Mobilgeräte
Integrierte Windows-Authentifizierung (IWA) Ermöglicht es Anwendungen auf Computern, die in eine Domäne oder in Microsoft Entra eingebunden sind, automatisch (also ohne Benutzerinteraktion über die Benutzeroberfläche) ein Token abzurufen. Desktop- und Mobilgeräte

Token

Ihre Anwendung kann einen oder mehrere Authentifizierungsflows verwenden. Jeder Flow verwendet für Authentifizierung, Autorisierung und Tokenaktualisierung bestimmte Tokentypen, und einige verwenden auch einen Autorisierungscode.

Authentifizierungsflow oder -aktion Erforderlich ID-Token Zugriffstoken Aktualisierungstoken Authorization code (Autorisierungscode)
Autorisierungscodeflow Der Authentifizierungsfluss funktioniert für ID-Token Der Authentifizierungsfluss funktioniert für Zugriffstoken Der Authentifizierungsfluss funktioniert für Aktualisierungstoken Der Autorisierungscode funktioniert
Clientanmeldeinformationen Der Authentifizierungsfluss funktioniert für Zugriffstoken (nur App)
Gerätecodeflow Der Authentifizierungsfluss funktioniert für ID-Token Der Authentifizierungsfluss funktioniert für Zugriffstoken Der Authentifizierungsfluss funktioniert für Aktualisierungstoken
Impliziter Flow Der Authentifizierungsfluss funktioniert für ID-Token Der Authentifizierungsfluss funktioniert für Zugriffstoken
„Im Auftrag von“-Ablauf Zugriffstoken Der Authentifizierungsfluss funktioniert für ID-Token Der Authentifizierungsfluss funktioniert für Zugriffstoken Der Authentifizierungsfluss funktioniert für Aktualisierungstoken
Benutzername/Kennwort (ROPC) Benutzername/Kennwort Der Authentifizierungsfluss funktioniert für ID-Token Der Authentifizierungsfluss funktioniert für Zugriffstoken Der Authentifizierungsfluss funktioniert für Aktualisierungstoken
Hybrid-OIDC-Ablauf Der Authentifizierungsfluss funktioniert für ID-Token Der Autorisierungscode funktioniert
Einlösung des Aktualisierungstokens Aktualisierungstoken Der Authentifizierungsfluss funktioniert für ID-Token Der Authentifizierungsfluss funktioniert für Zugriffstoken Der Authentifizierungsfluss funktioniert für Aktualisierungstoken

Interaktive und nicht interaktive Authentifizierung

Verschiedene dieser Flows unterstützen sowohl interaktive als auch nicht interaktive Tokenkäufe.

  • Interaktiv: Der Benutzer kann vom Autorisierungsserver zu einer Eingabe aufgefordert werden. Führen Sie beispielsweise zum Anmelden die Multi-Faktor-Authentifizierung (MFA) durch, oder erteilen Sie die Einwilligung für mehr Ressourcenzugriffsberechtigungen.
  • Nicht interaktiv (stumm) – Der Benutzer wird möglicherweise nicht zu einer Eingabe aufgefordert. Wird auch als automatischer Tokenabruf bezeichnet. Die Anwendung versucht, ein Token mithilfe einer Methode abzurufen, bei der der Autorisierungsserver den Benutzer ggf. nicht zu einer Eingabe auffordert.

Ihre MSAL-basierte Anwendung sollte zunächst versuchen, ein Token automatisch zu beziehen und erst dann auf die interaktive Methode zurückgreifen, wenn der nicht-interaktive Versuch fehlschlägt. Weitere Informationen finden Sie unter Abrufen und Zwischenspeichern von Token mithilfe der Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL).

Authorization code (Autorisierungscode)

Die OAuth 2.0-Autorisierungscodezuweisung kann von Web-Apps, Single-Page-Apps (SPA) und nativen (mobilen und Desktop-) Apps verwendet werden, um Zugriff auf geschützte Ressourcen wie Web-APIs zu erhalten.

Wenn sich Benutzer bei Webanwendungen anmelden, erhält die Anwendung einen Autorisierungscode, den sie gegen ein Zugriffstoken einlösen kann, um Web-APIs aufzurufen.

Die Anwendung im folgenden Diagramm:

  1. Fordert einen Autorisierungscode an, der gegen ein Zugriffstoken eingelöst wurde
  2. Verwendet das Zugriffstoken zum Aufrufen einer Web-API, Microsoft Graph

Diagramm: Autorisierungscodefluss.

Einschränkungen für Autorisierungscode

  • Für Single-Page-Webanwendungen ist ein Proof Key For Code Exchange (PKCE) erforderlich, wenn der Flow bei Zuweisung des Autorisierungscode verwendet wird. PKCE wird von MSAL unterstützt.

  • Die OAuth 2.0-Spezifikation verlangt, dass Sie einen Autorisierungscode verwenden, um ein Zugriffstoken einmalig einzulösen.

    Wenn Sie versuchen, das Zugriffstoken mehrmals mit demselben Autorisierungscode abzurufen, gibt die Microsoft Identity Platform eine Fehlermeldung ähnlich der folgenden zurück. Einige Bibliotheken und Frameworks fordern den Autorisierungscode automatisch für Sie an. Das manuelle Anfordern eines Codes führt in solchen Fällen ebenfalls zu diesem Fehler.

    AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

Client credentials (Clientanmeldeinformationen)

Mit dem OAuth 2.0-Clientanmeldeinformationsflow können Sie über die Identität einer Anwendung auf im Web gehostete Ressourcen zugreifen. Diese Art der Gewährung wird häufig für Interaktionen zwischen Servern verwendet, die ohne Benutzereingriff im Hintergrund ausgeführt werden müssen. Diese Anwendungstypen werden oft als Daemons oder Dienstkonten bezeichnet.

Beim Fluss zur Zuweisung von Clientanmeldeinformationen kann ein Webdienst (ein vertraulicher Client) seine eigenen Anmeldeinformationen zum Authentifizieren verwenden, wenn ein anderer Webdienst aufgerufen wird, anstatt die Identität eines Benutzers anzunehmen. In diesem Szenario ist der Client normalerweise ein Webdienst der mittleren Ebene, ein Daemondienst oder eine Website. Für ein höheres Maß an Sicherheit bietet die Microsoft Identity Platform auch die Möglichkeit, dass der aufrufende Dienst ein Zertifikat (statt eines gemeinsamen Geheimnisses) als Anmeldeinformationen verwendet.

Anwendungsgeheimnisse

Die Anwendung im folgenden Diagramm:

  1. Ruft ein Token mithilfe des Anwendungsgeheimnisses oder den Kennwortanmeldeinformationen ab
  2. Verwendet das Token für Anforderungen an die Ressource

Diagramm: Vertraulicher Client mit Kennwort

Zertifikate

Die Anwendung im folgenden Diagramm:

  1. Ruft ein Token mithilfe der Zertifikatanmeldeinformationen ab
  2. Verwendet das Token für Anforderungen an die Ressource

Diagramm: Vertraulicher Client mit Zertifikat

Die Clientanmeldeinformationen müssen folgende Voraussetzungen erfüllen:

  • Registriert mit Microsoft Entra ID
  • Wurde bei der Erstellung des vertraulichen Clientanwendungobjekts in Ihrem Code übergeben

Einschränkungen für Clientanmeldeinformationen

Der vertrauliche Clientflow wird für mobile Plattformen wie Android, iOS oder UWP nicht unterstützt. Mobile Anwendungen gelten als öffentliche Clientanwendungen, die nicht in der Lage sind, die Vertraulichkeit ihrer Anmeldeinformationen zu gewährleisten.

Gerätecode

Der OAuth 2.0-Gerätecodeflow ermöglicht es Benutzern, sich bei Geräten mit Eingabeeinschränkungen wie Smart-TVs, IoT-Geräten oder Druckern anzumelden. Die interaktive Authentifizierung mit Microsoft Entra ID erfordert einen Webbrowser. Wenn das Gerät oder Betriebssystem keinen Webbrowser bereitstellt, ermöglicht es der Gerätecodeflow dem Benutzer, ein anderes Gerät (z. B. einen anderen Computer oder ein anderes Mobiltelefon) zu verwenden, um sich interaktiv anzumelden.

Mithilfe des Gerätecodeflows ruft die Anwendung Token in einem zweistufigen Prozess ab, der für diese Geräte und Betriebssysteme entwickelt wurde. Beispiele sind Anwendungen, die auf IoT-Geräten oder Befehlszeilentools (CLI-Tools) ausgeführt werden.

Das Diagramm weiter unten zeigt Folgendes:

  1. Sobald eine Benutzerauthentifizierung erforderlich ist, stellt die App einen Code bereit und fordert den Benutzer auf, mit einem anderen Gerät wie z. B. einem Smartphone mit Internetverbindung eine URL (z. B. https://microsoft.com/devicelogin) aufzurufen. Der Benutzer wird dann zur Eingabe des Codes aufgefordert und durch eine normale Authentifizierungserfahrung geführt, einschließlich Einwilligungsaufforderungen und Multi-Faktor-Authentifizierung, falls notwendig.
  2. Nach erfolgreicher Authentifizierung empfängt die Befehlszeilen-App die erforderlichen Token über einen Backchannel und führt damit die benötigten Web-API-Aufrufe aus.

Diagramm: Gerätecodefluss

Einschränkungen für Gerätecode

  • Der Gerätecodeflow ist nur für öffentliche Clientanwendungen verfügbar.
  • Wenn Sie eine öffentliche Clientanwendung in MSAL initialisieren, verwenden Sie eines dieser Autoritätsformate:
    • Mandant: https://login.microsoftonline.com/{tenant}/,, wobei {tenant} entweder die Mandanten-ID oder ein Domänenname ist, die/der dem Mandanten zugeordnet ist.
    • Geschäfts-, Schul- oder Unikonten: https://login.microsoftonline.com/organizations/.

Implicit grant (Implizite Gewährung)

Der implizite Genehmigungsflow wurde durch den Autorisierungscodeflow mit PKCE als bevorzugter und sichererer Flow zur Zuweisung von Token für clientseitige Einzelseitenanwendungen (Single Page-Applications, SPAs) ersetzt.

Warnung

Es wird nicht mehr empfohlen, den impliziten Genehmigungsflow zu verwenden. Wenn Sie eine SPA entwickeln, verwenden Sie stattdessen den Autorisierungscodeflow mit PKCE.

In JavaScript geschriebene Single-Page-Apps (einschließlich Frameworks wie Angular, Vue.js oder React.js) werden vom Server heruntergeladen, und ihr Code wird direkt im Browser ausgeführt. Da ihr clientseitiger Code im Browser und nicht auf einem Webserver ausgeführt wird, haben sie andere Sicherheitsmerkmale als herkömmliche serverseitige Webanwendungen. Vor der Verfügbarkeit von Proof Key for Code Exchange (PKCE) für den Autorisierungscodeflow wurde der Flow mit impliziter Genehmigung von SPAs verwendet, um die Reaktionsfähigkeit und Effizienz beim Abrufen von Zugriffstoken zu verbessern.

Der OAuth 2.0-Flow zur impliziten Genehmigung ermöglicht es der App, Zugriffstoken von der Microsoft Identity Platform abzurufen, ohne dass ein Austausch von Anmeldeinformationen auf dem Back-End-Server erfolgt. Der Flow zur impliziten Genehmigung ermöglicht es einer App, den Benutzer anzumelden, eine Sitzung aufrechtzuerhalten und Token für andere Web-APIs aus dem JavaScript-Code abzurufen, der vom Benutzer-Agent (in der Regel ein Webbrowser) heruntergeladen und ausgeführt wird.

Diagramm: Fluss für implizite Genehmigung

Einschränkungen für die implizite Genehmigung

Der Flow zur impliziten Genehmigung umfasst keine Anwendungsszenarien, in denen plattformübergreifende JavaScript-Frameworks wie Electron oder React Native zum Einsatz kommen. Plattformübergreifende Frameworks wie diese benötigen weitere Funktionen für die Interaktion mit den nativen Desktop- und mobilen Plattformen, auf denen sie ausgeführt werden.

Token, die über den impliziten Flowmodus ausgegeben werden, haben eine Längenbeschränkung, da sie über die URL an den Browser zurückgegeben werden (wobei response_mode entweder query oder fragmentist). Einige Browser beschränken die Länge der URL in der Browserleiste und geben einen Fehler aus, wenn sie zu lang ist. Daher enthalten diese impliziten Flowtoken keine groups- oder wids-Ansprüche.

OBO (On-Behalf-Of, Im Auftrag von)

Der OAuth 2.0-On-Behalf-Of-Authentifizierungsflow wird verwendet, wenn eine Anwendung einen Dienst oder eine Web-API aufruft, der/die wiederum einen anderen Dienst oder eine Web-API aufrufen muss. Die Idee dabei ist, die delegierte Benutzeridentität und Berechtigungen über die Anforderungskette weiterzugeben. Damit der Dienst auf der mittleren Ebene Authentifizierungsanforderungen an den Downstreamdienst stellen kann, muss im Namen des Benutzers ein Zugriffstoken der Microsoft Identity Platform gesichert werden.

Das Diagramm weiter unten zeigt Folgendes:

  1. Die Anwendung ruft ein Zugriffstoken für die Web-API ab.
  2. Ein Client (Webanwendung, Desktopanwendung, mobile Anwendung oder Single-Page-Webanwendung) ruft eine geschützte Web-API auf und fügt dabei das Zugriffstoken als Bearertoken in den Authentifizierungsheader der HTTP-Anforderung ein. Die Web-API authentifiziert den Benutzer.
  3. Wenn der Client die Web-API aufruft, fordert diese ein weiteres Token im Namen des (On-Behalf-Of) Benutzers an.
  4. Die geschützte Web-API verwendet dieses Token, um eine Downstream-Web-API im Namen des Benutzers aufzurufen. Die Web-API kann später auch Token für andere Downstream-APIs anfordern (allerdings immer noch im Namen desselben Benutzers).

Diagramm: On-Behalf-Of-Fluss

Benutzername/Kennwort (ROPC)

Die OAuth 2.0-Genehmigung für Kennwortanmeldeinformationen des Ressourcenbesitzers (Resource Owner Password Credentials, ROPC) ermöglicht es einer Anwendung, Benutzer anzumelden, indem sie das Kennwort direkt verarbeitet. Sie können in Ihrer Desktopanwendung den Benutzername/Kennwort-Flow verwenden, um ein Token automatisch abzurufen. Bei Verwendung der Anwendung ist keine Benutzeroberfläche erforderlich.

Warnung

Der ROPC-Flow (Resource Owner Password Credentials, Kennwortanmeldeinformationen des Ressourcenbesitzers) wird NICHT empfohlen. ROPC erfordert ein hohes Maß an Vertrauenswürdigkeit und Offenlegung von Anmeldeinformationen. Greifen Sie nur dann auf ROPC zurück, wenn kein sichererer Flow verwendet werden kann. Weitere Informationen finden Sie unter What's the solution to the growing problem of passwords? (Wie sich das zunehmende Problem der Passwörter lösen lässt.).

Die Anwendung im folgenden Diagramm:

  1. Ruft ein Token ab, indem der Benutzername und das Kennwort an den Identitätsanbieter gesendet werden
  2. Ruft eine Web-API mithilfe des Tokens auf

Diagramm: Benutzername/Kennwort-Fluss

Um ein Token automatisch auf Computern zu beziehen, die in eine Windows-Domäne eingebunden sind, empfehlen wir die integrierte Windows-Authentifizierung (IWA) anstelle von ROPC. Verwenden Sie in anderen Szenarien den Gerätecodeflow.

Einschränkungen für ROPC

Die folgenden Einschränkungen gelten für Anwendungen, die den ROPC-Flow verwenden:

  • Einmaliges Anmelden wird nicht unterstützt.
  • Die Multi-Faktor-Authentifizierung (MFA) wird nicht unterstützt.
    • Informieren Sie sich bei Ihrem Mandantenadministrator, bevor Sie diesen Flow verwenden. MFA ist ein gängiges Feature.
  • Bedingter Zugriff wird nicht unterstützt.
  • ROPC funktioniert ausschließlich für Geschäfts-, Schul- oder Unikonten.
  • Persönliche Microsoft-Konten (MSA) werden von ROPC nicht unterstützt.
  • ROPC wird in .NET-Desktop- und ASP.NET Core-Anwendungen unterstützt.
  • ROPC wird in UWP-Anwendungen (Universelle Windows-Plattform) nicht unterstützt.
  • ROPC in Azure AD B2C wird ausschließlich für lokale Konten unterstützt.

Integrierte Windows-Authentifizierung (IWA)

MSAL unterstützt die integrierte Windows-Authentifizierung (IWA) für Desktopanwendungen und mobile Anwendungen auf Windows-Computern, die in eine Domäne oder in Microsoft Entra eingebunden sind. Mithilfe der IWA können diese Anwendungen automatisch ein Token beziehen, ohne dass der Benutzer mit der Benutzeroberfläche interagieren muss.

Die Anwendung im folgenden Diagramm:

  1. Ruft ein Token mithilfe der integrierten Windows-Authentifizierung ab
  2. Verwendet das Token für Anforderungen an die Ressource

Diagramm: Integrierte Windows-Authentifizierung

Einschränkungen für die IWA

Kompatibilität

Die integrierte Windows-Authentifizierung (IWA) ist für .NET-Desktop-, .NET- und UWP-Apps (Universelle Windows-Plattform) aktiviert.

Die IWA unterstützt ausschließlich AD FS-Verbundbenutzer*innen (also Benutzer*innen, die in Active Directory erstellt und von Microsoft Entra ID unterstützt werden). Direkt in Microsoft Entra ID erstellte Benutzer*innen ohne Active Directory-Unterstützung (verwaltete Benutzer*innen) können diesen Authentifizierungsflow nicht verwenden.

Multi-Faktor-Authentifizierung (MFA)

Die nicht interaktive (automatische) Authentifizierung der IWA ist möglicherweise nicht erfolgreich, wenn MFA im Microsoft Entra-Mandanten aktiviert ist und eine MFA-Aufforderung von Microsoft Entra ID ausgegeben wird. Wenn die IWA fehlschlägt, sollten Sie auf eine interaktive Authentifizierungsmethode wie oben beschrieben zurückgreifen.

Microsoft Entra ID nutzt KI, um zu ermitteln, ob eine Zwei-Faktor-Authentifizierung erforderlich ist. Die zweistufige Authentifizierung ist in der Regel erforderlich, wenn sich ein Benutzer aus einem anderen Land/einer anderen Region anmeldet, wenn er mit einem Unternehmensnetzwerk verbunden ist, ohne ein VPN zu verwenden, und gelegentlich, wenn er über ein VPN verbunden ist. Da die Konfiguration der MFA und die Häufigkeit der Aufforderung möglicherweise außerhalb Ihrer Kontrolle als Entwickler liegen, sollte Ihre Anwendung einen Fehler beim automatischen Bezug von Token über die IWA angemessen behandeln.

Einschränkungen des Autoritäts-URI

Die beim Erstellen der öffentlichen Clientanwendung übergebene Autorität muss eine der folgenden Voraussetzungen erfüllen:

  • https://login.microsoftonline.com/{tenant}/: Diese Autorität gibt eine Einzelinstanzanwendung an, bei der sich nur die Benutzer*innen des angegebenen Microsoft Entra-Mandanten anmelden können. Der Wert {tenant} kann die Mandanten-ID in Form einer GUID oder der dem Mandanten zugeordnete Domänenname sein.
  • https://login.microsoftonline.com/organizations/: Diese Autorität gibt eine mehrinstanzenfähige Anwendung an, bei der sich Benutzer*innen aus einem beliebigen Microsoft Entra-Mandanten anmelden können.

Autoritätswerte dürfen NICHT /common oder /consumers enthalten, da persönliche Microsoft-Konten (MSA) von der IWA nicht unterstützt werden.

Anforderungen der Einwilligung

IWA ist ein automatischer Flow, sodass

  • Der Benutzer muss vorher in die Nutzung Ihrer Anwendung eingewilligt haben.

    OR

  • Der Mandantenadministrator muss vorher im Namen aller Benutzer in die Nutzung der Anwendung eingewilligt haben.

Um eine der beiden Anforderungen zu erfüllen, muss einer dieser Vorgänge abgeschlossen werden:

  • Sie als der Anwendungsentwickler haben im Azure-Portal Gewähren für sich selbst ausgewählt.
  • Ein Mandantenadministrator hat bei der App-Registrierung im Azure-Portal auf der Registerkarte API-Berechtigungen die Option Administratorzustimmung für {Mandantendomäne} erteilen/widerrufen ausgewählt (weitere Informationen finden Sie unter Hinzufügen von Zugriffsberechtigungen für Ihre Web-API).
  • Sie haben den Benutzern eine Möglichkeit gegeben, der Anwendung zuzustimmen: siehe Benutzereinwilligung.
  • Sie haben dem Mandantenadministrator eine Möglichkeit gegeben, der Anwendung zuzustimmen: siehe Administratoreinwilligung.

Weitere Informationen zur Zustimmung finden Sie unter Berechtigungen und Zustimmung.

Nächster Schritt

Erfahren Sie mehr über das Abrufen und Zwischenspeichern der in diesen Flows verwendeten Token:

Abrufen und Zwischenspeichern von Token mithilfe der Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL)