Freigeben über

In MSAL unterstützte Authentifizierungsflüsse

  • Artikel

Microsoft Authentication Library (MSAL) unterstützt mehrere Autorisierungserteilungen und zugehörige Tokenflüsse für die Verwendung durch verschiedene Anwendungstypen und Szenarien.

Authentifizierungsfluss ermöglicht Unterstützte Anwendungstypen
Autorisierungscode Benutzeranmeldung und Zugriff auf Web-APIs im Namen des Benutzers. * 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 Benutzeranmeldung und Zugriff auf Web-APIs im Namen des Benutzers auf eingabeeinschränkten Geräten, z. B. smarte TVs und Internet of Things (IoT)-Geräte. 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 Genehmigungsfluss wird nicht mehr empfohlen – verwenden Sie stattdessen Autorisierungscode mit Proof Key für 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, die auf Computern in Verbindung mit der Microsoft Entra-ID ausgeführt werden Standard ein Token automatisch zu erwerben (ohne Benutzeroberflächeninteraktion vom Benutzer). 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. Auch als automatische Tokenerfassung bezeichnet, versucht die Anwendung, ein Token mithilfe einer Methode abzurufen, in 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-Autorisierungscodeerteilung kann von Web-Apps, Einzelseiten-Apps (SPA) und systemeigenen Anwendungen (Mobile und Desktop) 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 zum Aufrufen einer Web-API, z. B. Microsoft Graph.

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, ein Zugriffstoken mehrmals mit demselben Autorisierungscode zu erwerben, wird ein Fehler ähnlich dem folgenden von der Microsoft Identity Platform 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 von Gewährung wird häufig für Server-zu-Server-Interaktionen (S2S) verwendet, die im Hintergrund ausgeführt werden müssen, ohne sofortige Interaktion von einem Benutzer. 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. Erwirbt ein Token mithilfe eines Anwendungsgeheimnisses oder Kennwortanmeldeinformationen.
  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 folgendes sein:

  • 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 geheimer Authentifizierungsgeheimnisse zu garantieren.

Gerätecode

Der OAuth 2-Gerätecodefluss ermöglicht Es Benutzern, sich bei eingabeeinschränkten Geräten wie Smart TVs, Internet of Things (IoT)-Geräten 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, ein anderes Gerät wie einen Computer oder ein Mobiltelefon 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.

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 aufgefordert, den Code einzugeben, und geht bei Bedarf über eine normale Authentifizierungserfahrung fort, einschließlich Zustimmungsaufforderungen und mehrstufiger Authentifizierung.
  2. Bei erfolgreicher Authentifizierung empfängt die anfordernde Anwendung die erforderlichen Token von der Microsoft Identity Platform und verwendet sie, um die benötigten Web-API-Aufrufe auszuführen.

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} handelt es sich entweder um die GUID, die die Mandanten-ID darstellt, oder eine Do Standard Name, 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 erfordern zusätzliche Funktionen für die Interaktion mit den systemeigenen 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 in der URL an den Browser zurückgegeben werden (wo response_mode entweder query oder fragment). 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-Fluss im Auftrag des Authentifizierungsflusses wird verwendet, wenn eine Anwendung einen Dienst oder eine Web-API aufruft, die wiederum einen anderen Dienst oder eine Web-API mithilfe einer delegierten Benutzeridentität und Berechtigungen aufrufen muss, die über die Anforderungskette weitergegeben werden müssen. Damit der Dienst auf mittlerer Ebene authentifizierte Anforderungen an den downstream-Dienst durchführt, muss es ein Zugriffstoken aus der Microsoft Identity Platform im Namen des anfordernden Benutzers sichern.

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 weiteres 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-Fluss (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 Fluss 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 möglicherweise ROPC nützlich, sollten aber in jeder Anwendung vermieden werden, 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.

Um ein Token automatisch auf Windows do Standard-verbundenen Computern zu erwerben, empfehlen wir die Verwendung des Web Account Manager (WAM) 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-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 im Hintergrund anmelden. Dieser Workflow erfordert keine komplexe Einrichtung und funktioniert sogar für persönliche (Microsoft)-Konten. Intern versucht der Windows Broker (WAM) mehrere Strategien zum Abrufen eines Tokens für den aktuellen Windows-Benutzer, einschließlich IWA und Einlösen des PRT. Dadurch werden die meisten Einschränkungen bei IWA beseitigt.

MSAL unterstützt integrierte Windows-Authentifizierung (IWA) für Desktop- und mobile Anwendungen, die auf do ausgeführt werden Standard oder in Microsoft Entra ID eingebundene Windows-Computer. 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 gesichert wurden. Direkt in Microsoft Entra ID erstellte Benutzer*innen ohne Active Directory-Unterstützung (verwaltete Benutzer*innen) können diesen Authentifizierungsflow nicht verwenden.
  • Mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) Die nicht interaktive (automatische) Authentifizierung kann fehlschlagen, wenn MFA im Microsoft Entra ID-Mandanten aktiviert ist und eine MFA-Abfrage 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 MFA-Konfiguration und Die Herausforderungshäufigkeit möglicherweise außerhalb Ihrer Kontrolle als Entwickler liegt, sollte Ihre Anwendung ordnungsgemäß einen Fehler der automatischen IWA-Tokenerfassung behandeln.
  • Autoritäts-URI-Einschränkungen. Die Beim Erstellen der öffentlichen Clientanwendung übergebene Autorität muss eine der folgenden Sein:
    • https://login.microsoftonline.com/{tenant}/ – Diese Autorität gibt eine Einzelmandantenanwendung an, deren Anmeldezielgruppe 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 Mehrinstanzenanwendung an, deren Anmeldezielgruppe Benutzer in einem beliebigen Microsoft Entra ID-Mandanten ist.
  • Persönliche Konten. Autoritätswerte dürfen weder enthalten /common/consumers noch weil persönliche Microsoft-Konten (MSA) von IWA nicht unterstützt werden.
  • Zustimmungsanforderungen. Da IWA ein automatischer Ablauf ist, muss der Benutzer Ihrer Anwendung zuvor zugestimmt haben, die Anwendung zu verwenden, oder der Mandantenadministrator muss zuvor allen Benutzern im Mandanten zugestimmt haben, die Anwendung zu verwenden. Um eine der beiden Anforderungen zu erfüllen, muss eine dieser Vorgänge abgeschlossen sein:

Nächste Schritte

Nachdem Sie die von MSAL unterstützten Authentifizierungsflüsse überprüft haben, erfahren Sie mehr über das Abrufen und Zwischenspeichern der in diesen Flüssen verwendeten Token.