Unterstützung des Authentifizierungsflows in der MSAL

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
* Mobilgerät
* Single-Page-App (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. Der implizite Zuweisungsflow wird nicht mehr empfohlen. Verwenden Sie stattdessen den Autorisierungscode mit PKCE. * 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. Der ROPC-Flow wird NICHT empfohlen. Desktop- und Mobilgeräte
Integrierte Windows-Authentifizierung (IWA) Ermöglicht es Anwendungen auf Computern, die in eine Domäne oder in Azure Active Directory (Azure AD) eingebunden sind, ohne Eingriff des Benutzers über die Benutzeroberfläche automatisch 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 x x x x
Clientanmeldeinformationen x (nur App)
Gerätecodeflow x x x
Impliziter Flow x x
„Im Auftrag von“-Ablauf Zugriffstoken x x x
Benutzername/Kennwort (ROPC) Benutzername/Kennwort x x x
Hybrid-OIDC-Ablauf x x
Einlösung des Aktualisierungstokens Aktualisierungstoken x x x

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 für die Anmeldung die Multi-Faktor-Authentifizierung (MFA) durch, oder erteilen Sie die Zustimmung zu mehr Ressourcenzugriffsberechtigungen.
  • Nicht interaktiv: 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.

Diagram of authorization code flow

Im obigen Diagramm führt die Anwendung folgende Vorgänge aus:

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

Einschränkungen für Autorisierungscode

  • Single-Page-Apps erfordern Proof Key For Code Exchange (PKCE) bei Verwendung des Zuweisungsflows für Autorisierungscode. 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. Denken Sie daran, dass einige Bibliotheken und Frameworks den Autorisierungscode automatisch für Sie anfordern. Die manuelle Anforderung 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-Clientanmeldeinformations-Flow können Sie über die Identität einer Anwendung auf Ressourcen zugreifen, die im Web gehostet werden. 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

Diagram of confidential client with password

Im obigen Diagramm führt die Anwendung folgende Vorgänge aus:

  1. Sie ruft ein Token mithilfe der Anmeldeinformationen ab, die aus einem Anwendungsgeheimnis oder Kennwort bestehen.
  2. Verwendet das Token für Anforderungen an die Ressource.

Zertifikate

Diagram of confidential client with cert

Im obigen Diagramm führt die Anwendung folgende Vorgänge aus:

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

Die Clientanmeldeinformationen müssen folgende Voraussetzungen erfüllen:

  • Sie wurden in Azure AD registriert.
  • Sie wurden bei der Erstellung des vertraulichen Clientanwendungobjekts im 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-Gerätecodeflow ermöglicht es Benutzern, sich bei Geräten mit Eingabeeinschränkung wie einem Smart-TV, einem IoT-Gerät oder einem Drucker anzumelden. Für die interaktive Authentifizierung mit Azure AD wird ein Webbrowser benötigt. 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.

Diagram of device code flow

Im obigen Diagramm ist Folgendes zu sehen:

  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 einen normalen Authentifizierungsprozess geführt, der ggf. auch Zustimmungsaufforderungen und die mehrstufige Authentifizierung umfasst.
  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.

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:
    • Mandanten im Format https://login.microsoftonline.com/{tenant}/,, wobei {tenant} entweder die GUID ist, die die Mandanten-ID darstellt, oder ein Domänenname, der dem Mandanten zugeordnet ist.
    • Geschäfts-, Schul- oder Unikonten: https://login.microsoftonline.com/organizations/.

Implicit grant (Implizite Gewährung)

Die implizite Genehmigung wurde durch den Autorisierungscodeflow mit PKCE als bevorzugter und sichererer Flow zur Zuweisung von Token für clientseitige Single-Page-Apps (SPAs) ersetzt. 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-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.

Diagram of implicit grant flow

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-On-Behalf-Of-Authentifizierungsflow wird verwendet, wenn eine Anwendung eine Dienst- oder Web-API aufruft, die wiederum eine andere Dienst- oder 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.

Diagram of on-behalf-of flow

Im obigen Diagramm ist Folgendes zu sehen:

  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).

Benutzername/Kennwort (ROPC)

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 OAuth 2-Gewährung für Kennwortanmeldeinformationen des Ressourcenbesitzers (Resource Owner Password Credentials, ROPC) ermöglicht es einer Anwendung, Benutzer anzumelden, indem sie ihr 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.

In einigen Anwendungsszenarien wie DevOps ist ROPC möglicherweise nützlich, aber Sie sollten es in jeder Anwendung vermeiden, in der Sie eine interaktive Benutzeroberfläche für die Benutzeranmeldung anbieten.

Diagram of the username/password flow

Im obigen Diagramm führt die Anwendung folgende Vorgänge aus:

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

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.
  • 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 .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 Desktop- und mobile Anwendungen auf Windows-Computern, die in eine Domäne oder Azure AD eingebunden sind. Mithilfe der IWA können diese Anwendungen automatisch ein Token beziehen, ohne dass der Benutzer mit der Benutzeroberfläche interagieren muss.

Diagram of integrated Windows authentication

Im obigen Diagramm führt die Anwendung folgende Vorgänge aus:

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

Einschränkungen für die IWA

Kompatibilität

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

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

So funktioniert's: Azure Multi-Factor Authentication

Die nicht interaktive (automatische) Authentifizierung der IWA kann fehlschlagen, wenn MFA im Azure AD-Mandanten aktiviert ist und eine MFA-Aufforderung von Azure AD ausgestellt wird. Wenn die IWA fehlschlägt, sollten Sie auf eine interaktive Authentifizierungsmethode wie oben beschrieben zurückgreifen.

Azure AD greift auf KI zurück, um zu ermitteln, ob eine zweistufige 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 Anwendung mit einem Mandanten an, bei der sich nur die Benutzer des angegebenen Azure AD-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 in einem beliebigen Azure AD-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 eine Möglichkeit für Benutzer eingeräumt, der Anwendung zuzustimmen (siehe Anfordern der Zustimmung einzelner Benutzer).
  • Sie haben eine Möglichkeit für den Mandantenadministrator eingeräumt, der Anwendung zuzustimmen (siehe Zustimmung des Administrators).

Weitere Informationen zur Zustimmung finden Sie unter Berechtigungen und Zustimmung.

Nächste Schritte

Nachdem Sie die von der MSAL unterstützten Authentifizierungsflows überprüft haben, können Sie sich über das Abrufen und Zwischenspeichern der in diesen Flows verwendeten Token informieren:

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