In MSAL unterstützte Authentifizierungsflows

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

Tokens

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.

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. Um sich beispielsweise anzumelden, die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) durchzuführen oder die Zustimmung zu weiteren Ressourcenzugriffsberechtigungen zu erteilen.
• Nicht interaktiv – Der Benutzer wird möglicherweise nicht zur Eingabe aufgefordert. Auch als stille Tokenerfassung bezeichnet, versucht die Anwendung, ein Token mithilfe einer Methode abzurufen, bei der der Autorisierungsserver den Benutzer 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), 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.

Im vorherigen Diagramm die Anwendung:

1. Fordert einen Autorisierungscode an, der für ein Zugriffstoken eingelöst wurde.
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) (Prüfschlüssel für den Codeaustausch) erforderlich, wenn der Flow der Autorisierungscodegenehmigung verwendet wird. PKCE wird von MSAL unterstützt.

• Die OAuth 2.0-Spezifikation erfordert, dass Sie einen Autorisierungscode verwenden, um ein Zugriffstoken nur einmal 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. Beachten Sie, dass einige Bibliotheken und Frameworks automatisch den Autorisierungscode für Sie anfordern, und das manuelle Anfordern eines Codes in solchen Fällen führt 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.

Clientanmeldeinformationen

Der OAuth 2-Clientanmeldeinformationsfluss ermöglicht ihnen den Zugriff auf webgehostete Ressourcen mithilfe der Identität einer Anwendung. 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.

Der Client-Credentials-Grant-Fluss erlaubt es einem Webdienst (einem vertraulichen Client), seine eigenen Anmeldeinformationen zu verwenden, um sich zu authentifizieren, wenn er einen anderen Webdienst aufruft, 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

Im vorherigen Diagramm die Anwendung:

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

Certificates

Im vorherigen Diagramm die Anwendung:

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

Diese Art von Clientanmeldeinformationen muss folgende Anforderungen erfüllen:

• Registriert bei Azure AD.
• 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.

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 oder einen dem Mandanten zugeordneten Domänennamen darstellt.
  • Geschäfts-, Schul- oder Unikonten: https://login.microsoftonline.com/organizations/.

Implizite Genehmigung

Die implizite Erteilung wurde durch den Autorisierungscodefluss mit PKCE als bevorzugten und sichereren Token-Erteilungsfluss für clientseitige Single-Page-Anwendungen (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 PKCE (Proof Key for Code Exchange) für den Autorisierungscodeflow wurde der implizite Genehmigungsflow von SPAs verwendet, um die Reaktionsfähigkeit und Effizienz beim Abrufen von Zugriffstoken zu verbessern.

Der implizite OAuth 2-Genehmigungsfluss ermöglicht der App, Zugriffstoken von der Microsoft Identity Platform abzurufen, ohne einen Back-End-Server-Anmeldeinformationsaustausch durchzuführen. 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.

Einschränkungen für die implizite Genehmigung

Der Ablauf des impliziten Genehmigungsprozesses umfasst keine Szenarien, in denen plattformübergreifende JavaScript-Frameworks wie Electron oder React Native verwendet werden. 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.

Im Auftrag von (OBO)

Der OAuth 2-On-Behalf-Of-Authentifizierungsflow wird verwendet, wenn eine Anwendung einen Dienst oder eine Web-API aufruft, der/die wiederum einen anderen Dienst oder eine andere Web-API mit einer delegierten Benutzeridentität und Berechtigungen aufrufen muss, die sich durch die Anforderungskette verbreiten 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.

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)

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.

Im vorherigen Diagramm die Anwendung:

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

Um ein Token automatisch auf Windows-Computern zu erwerben, die einer Domäne beigetreten sind, 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.
• Die mehrstufige Authentifizierung (Multi-Factor Authentication, 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- und Schulkonten.
• 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.
  • Informationen zu ROPC in MSAL.NET und der externen Microsoft Entra-ID finden Sie unter Resource Owner Password Credentials (ROPC) With B2C.

Integrierte Windows-Authentifizierung (IWA)

MSAL unterstützt die integrierte Windows-Authentifizierung (IWA) für Desktop- und mobile Anwendungen, die auf in die Domäne eingebundenen oder in Microsoft Entra ID integrierten 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.

Im vorherigen Diagramm die Anwendung:

1. Erwirbt ein Token mithilfe der integrierten Windows-Authentifizierung.
2. Verwendet das Token, um Ressourcenanforderungen zu stellen.

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. 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 (stille) Authentifizierung kann fehlschlagen, wenn MFA im Microsoft Entra ID-Mandanten aktiviert ist und Microsoft Entra ID eine MFA-Abfrage ausgibt. 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 manchmal, wenn er über ein VPN verbunden ist . Da die MFA-Konfiguration und die Häufigkeit der Herausforderungen möglicherweise außerhalb Ihrer Kontrolle als Entwickler liegen, sollte Ihre Anwendung ordnungsgemäß auf einen Fehler bei der stillen IWA-Tokenerfassung reagieren.
• 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/common oder /consumers nicht enthalten, da persönliche Microsoft-Konten (MSA) von IWA nicht unterstützt werden.
• Zustimmungsanforderungen. Da IWA ein stiller Ablauf ist, muss der Benutzer Ihrer Anwendung zuvor zugestimmt haben, die Anwendung zu verwenden, oder der Mandantenadministrator muss zuvor die Verwendung der Anwendung für alle Benutzer im Mandanten genehmigt haben. Um eine der beiden Anforderungen zu erfüllen, muss eine dieser Vorgänge abgeschlossen sein:
  • Sie als Anwendungsentwickler haben "Grant " im Azure-Portal 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 benutzern die Möglichkeit gegeben, der Anwendung zuzustimmen; siehe Übersicht über Berechtigungen und Zustimmung in der Microsoft Identity Platform.
  • Sie haben dem Mandantenadministrator die Möglichkeit gegeben, der Anwendung zuzustimmen; siehe Übersicht über Berechtigungen und Zustimmung in der Microsoft Identity Platform.

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.