In MSAL unterstützte Authentifizierungsflows

  • 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 Benutzeranmeldung und Zugriff auf Web-APIs im Namen des Benutzers. * 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 Benutzeranmeldung und Zugriff auf Web-APIs im Namen des Benutzers auf Geräten mit eingeschränkter Eingabe, z. B. Smart-TVs und IoT-Geräten (Internet der Dinge). 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 Ablauf der impliziten Gewährung wird nicht mehr empfohlen. Verwenden Sie stattdessen Autorisierungscode mit Proof Key for Code Exchange (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 Anwendungen auf Domänen- oder Microsoft Entra ID angeschlossenen Computern das automatische Abrufen eines Tokens (ohne Benutzeroberflächeninteraktion des Benutzers). 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 ✅ ✅ ✅ ✅
Clientanmeldeinformationen ✅ (nur App)
Gerätecodeflow ✅ ✅ ✅
Impliziter Flow ✅ ✅
„Im Auftrag von“-Ablauf Zugriffstoken ✅ ✅ ✅
Benutzername/Kennwort (ROPC) Benutzername, Kennwort ✅ ✅ ✅
Hybrid-OIDC-Ablauf ✅ ✅
Einlösung des Aktualisierungstokens 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 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. Die Anwendung wird auch als automatische Tokenerfassung bezeichnet und versucht, ein Token mithilfe einer Methode abzurufen, bei der der Autorisierungsserver den Benutzer möglicherweise nicht zur 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 Desktopanwendungen) 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.

Diagramm: Autorisierungscodefluss

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, um eine Web-API wie Microsoft Graph aufzurufen.

Einschränkungen für Autorisierungscode

  • Single-Page-Anwendungen erfordern proof key for Code Exchange (PKCE), wenn sie den Autorisierungscode-Gewährungsflow verwenden. 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, ein Zugriffstoken mehrmals mit demselben Autorisierungscode abzurufen, wird vom Microsoft Identity Platform ein Fehler ähnlich dem folgenden zurückgegeben. 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 Server-zu-Server-Interaktionen (S2S) verwendet, die im Hintergrund ohne sofortige Benutzerinteraktion ausgeführt werden müssen. Diese Arten von Anwendungen werden häufig als Daemons oder Dienste 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

Diagramm: vertraulicher Client mit Kennwort

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

  1. Ruft ein Token mithilfe eines Anwendungsgeheimnisses oder Kennwortanmeldeinformationen ab.
  2. Verwendet das Token, um Ressourcenanforderungen zu stellen.

Zertifikate

Diagramm: vertraulicher Client mit Zertifikat

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

  1. Sie ruft ein Token mithilfe der Zertifikatanmeldeinformationen ab.
  2. Verwendet das Token, um Ressourcenanforderungen zu stellen.

Diese Art von Clientanmeldeinformationen muss wie folgt lauten:

  • Sie wurden in Azure AD registriert.
  • Sie wurden bei der Erstellung des vertraulichen Clientanwendungobjekts im Code übergeben.

Einschränkungen für Clientanmeldeinformationen

Der vertrauliche Clientfluss wird auf mobilen Plattformen wie Android, iOS oder Universelle Windows-Plattform (UWP) nicht unterstützt. Mobile Anwendungen gelten als öffentliche Clientanwendungen, die nicht in der Lage sind, die Vertraulichkeit von Authentifizierungsgeheimnissen zu gewährleisten.

Gerätecode

Der OAuth 2-Gerätecodeflow ermöglicht es Benutzern, sich bei eingabebeschränkten Geräten wie Smart-TVs, IoT-Geräten (Internet of Things) und Druckern anzumelden. Die interaktive Authentifizierung mit Microsoft Entra ID erfordert einen Webbrowser. Wenn das Gerät oder Betriebssystem keinen Webbrowser bereitstellt, ermöglicht der Gerätecodefluss die Möglichkeit, sich interaktiv mit einem anderen Gerät wie einem Computer oder Mobiltelefon anzumelden.

Mithilfe des Gerätecodeflows ruft die Anwendung Token in einem zweistufigen Prozess ab, der für diese Geräte und Betriebssysteme entwickelt wurde.

Diagramm: Gerätecodefluss

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 fährt bei Bedarf mit einer normalen Authentifizierung fort, einschließlich Zustimmungsaufforderungen und mehrstufiger Authentifizierung.
  2. Nach erfolgreicher Authentifizierung empfängt die anfordernde Anwendung die erforderlichen Token vom Microsoft Identity Platform und verwendet sie, um die web-API-Aufrufe auszuführen, die sie benötigt.

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:
    • Mandantenbasiert: https://login.microsoftonline.com/{tenant}/, Dabei {tenant} ist entweder die GUID, 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.

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 erfordern zusätzliche Funktionen für die Interaktion mit den nativen Desktop- und mobilen Plattformen, auf denen sie ausgeführt werden.

Token, die über den impliziten Flussmodus ausgegeben werden, weisen eine Längenbeschränkung auf, da sie an den Browser in der URL 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-Ablauf im Auftrag der Authentifizierung wird verwendet, wenn eine Anwendung einen Dienst oder eine Web-API aufruft, die wiederum einen anderen Dienst oder eine Web-API aufrufen muss, indem eine delegierte Benutzeridentität und Berechtigungen verwendet werden, die über die Anforderungskette weitergegeben werden müssen. Damit der Dienst der mittleren Ebene authentifizierte Anforderungen an den nachgeschalteten Dienst senden kann, muss er ein Zugriffstoken vom Microsoft Identity Platform im Namen des anfordernden Benutzers schützen.

Diagramm: OBO-Fluss

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 die Web-API ein anderes Token im Namen des Benutzers an.
  4. Die geschützte Web-API verwendet dieses Token, um eine nachgeschaltete 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) wird nicht mehr empfohlen. ROPC erfordert ein hohes Maß an Vertrauenswürdigkeit und Offenlegung von Anmeldeinformationen. Verwenden Sie ROPC nur, wenn ein sichererer Flow nicht 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.

Einige Anwendungsszenarien, z. B. DevOps, finden ROPC möglicherweise nützlich, aber Sie sollten es in jeder Anwendung vermeiden, in der Sie eine interaktive Benutzeroberfläche für die Benutzeranmeldung bereitstellen.

Diagramm: Benutzername/Kennwort-Fluss

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.

Zum automatischen Abrufen eines Tokens auf Windows-Computern, die in die Domäne eingebunden sind, wird empfohlen, den Web Account Manager (WAM) anstelle von ROPC zu verwenden. 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-Anwendungen unterstützt .
  • ROPC wird in UWP-Anwendungen (Universelle Windows-Plattform) nicht unterstützt.
  • ROPC in Microsoft Entra External ID wird nur für lokale Konten unterstützt.

Integrierte Windows-Authentifizierung (IWA)

Hinweis

Die integrierte Windows-Authentifizierung wurde durch eine zuverlässigere Methode zum automatischen Abrufen von Token ersetzt: WAM. WAM kann den aktuellen Windows-Benutzer unbeaufsichtigt anmelden. Dieser Workflow erfordert keine komplexe Einrichtung und funktioniert sogar für persönliche (Microsoft)-Konten. Intern versucht der Windows Broker (WAM) mehrere Strategien, um ein Token für den aktuellen Windows-Benutzer zu erhalten, einschließlich IWA und Einlösen des PRT. Dadurch werden die meisten Einschränkungen mit IWA beseitigt.

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

Diagramm: integrierte Windows-Authentifizierung

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, um Ressourcenanforderungen zu stellen.

Einschränkungen für die IWA

  • Kompatibilität. Integrierte Windows-Authentifizierung (IWA) ist für .NET-Desktop-, .NET- und Universelle Windows-Plattform-Apps (UWP) aktiviert. IWA unterstützt nur ADFS-Verbundbenutzer– Benutzer, die in Active Directory erstellt und von Microsoft Entra ID unterstützt werden. Benutzer, die direkt in Microsoft Entra ID ohne Active Directory-Unterstützung erstellt wurden (verwaltete Benutzer), können diesen Authentifizierungsflow nicht verwenden.
  • Multi-Factor Authentication (MFA) Die nicht interaktive (unbeaufsichtigte) IWA-Authentifizierung kann fehlschlagen, wenn MFA im Microsoft Entra ID Mandanten aktiviert ist und eine MFA-Anforderung 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 verwendet KI, um zu bestimmen, wann 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 Konfigurations- und Herausforderungshäufigkeit von MFA außerhalb Ihrer Kontrolle als Entwickler liegt, sollte Ihre Anwendung einen Fehler der unbeaufsichtigten IWA-Tokenerfassung ordnungsgemäß behandeln.
  • Autoritäts-URI-Einschränkungen. 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 Einzelmandantenanwendung an, deren Anmeldegruppe auf die Benutzer im angegebenen Microsoft Entra ID-Mandanten beschränkt ist. 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, deren Anmeldeziel Benutzer in einem beliebigen Microsoft Entra ID Mandanten ist.
  • Persönliche Konten. Autoritätswerte dürfen keine oder /consumers enthalten/common, da persönliche Microsoft-Konten (MSA) von IWA nicht unterstützt werden.
  • Zustimmungsanforderungen. Da es sich bei der IWA um einen unbeaufsichtigten Ablauf handelt, muss der Benutzer Ihrer Anwendung zuvor der Verwendung der Anwendung zugestimmt haben, oder der Mandantenadministrator muss zuvor allen Benutzern im Mandanten zur Verwendung der Anwendung zugestimmt haben. Um eine der beiden Anforderungen zu erfüllen, muss einer dieser Vorgänge abgeschlossen werden:

Nächste Schritte

Nachdem Sie nun die von MSAL unterstützten Authentifizierungsflüsse überprüft haben, erfahren Sie mehr über das Abrufen und Zwischenspeichern der token, die in diesen Flows verwendet werden.