szenarien für MSAL.NET

Einleitung

Die .NET Authentifizierungsbibliotheken unterstützen Szenarien zum Schutz einer Web-API und zum Abrufen von Token für eine geschützte Web-API. MSAL.NET wird nur für letzteres verwendet.

Als Entwickler können Sie ein Token aus einer Reihe von Anwendungstypen abrufen, einschließlich Webanwendungen, mobilen Anwendungen, Desktopanwendungen, Web-APIs und Anwendung, die auf Geräten ohne Browser (oder iOT) ausgeführt wird. Diese Arten von Anwendungen sind in zwei Kategorien unterteilt:

• Öffentliche Clientanwendungen (Desktop und Mobil) verwenden die PublicClientApplication Klasse
• Vertrauliche Clientanwendungen (Web-Apps, Web-APIs und Daemon-Anwendungen – Desktop oder Web). Diese Art von Apps verwenden die ConfidentialClientApplication.

MSAL.NET unterstützt das Abrufen von Token entweder im Namen eines oder (und nur für vertrauliche Clientanwendungen) im Namen der Anwendung selbst (für keinen Benutzer). In diesem Fall gibt die vertrauliche Clientanwendung einen geheimen Schlüssel mit Microsoft Entra ID .

MSAL.NET unterstützt eine Reihe von Plattformen (.NET Framework, .NET und .NET MAUI). .NET Apps können auch auf verschiedenen Betriebssystemen (Windows, Linux und macOS) ausgeführt werden. Die Szenarien können je nach Plattform unterschiedlich sein.

Die Szenarien

Die folgende Abbildung fasst die unterstützten Szenarien zusammen und zeigt, auf welcher Plattform und welchem Microsoft Entra Protokoll dies entspricht:

Web-App, die Benutzer anmeldet und eine Web-API im Namen des Benutzers aufruft

Zum Schutz einer Web-App (Anmelden beim Benutzer) verwenden Sie ASP.NET oder ASP.NET Core mit der ASP.NET OpenID Connect-Middleware. Dies umfasst die Überprüfung des Tokens, das von den IdentityModel-Erweiterungen für .NET Bibliothek durchgeführt wird, nicht MSAL.NET.

Um die Web-API im Namen des Benutzers aufzurufen, verwenden Sie MSAL.NETConfidentialClientApplication, nutzen den Autorisierungscodefluss, speichern dann das erworbene Token im Tokencache und rufen ein Token bei Bedarf automatisch aus dem Cache ab. Durch MSAL wird das Token bei Bedarf aktualisiert.

Mobile App, die eine Web-API im Namen des Benutzers aufruft, der interaktiv angemeldet ist

Um eine Web-API aus einer mobilen Anwendung aufzurufen, verwenden Sie die interaktiven Tokenakquisitionsmethoden von publicClientApplication MSAL.NET. Mit diesen interaktiven Methoden können Sie die Anmeldebenutzeroberfläche sowie den Speicherort des interaktiven Dialogfelds auf einigen Plattformen steuern.

Um diese Interaktion zu aktivieren, nutzt MSAL.NET einen Webbrowser. Je nach mobiler Plattform gibt es Besonderheiten. Unter iOS und Android können Sie auswählen, ob Sie den Systembrowser (Standard) oder einen eingebetteten Webbrowser nutzen möchten. Sie können die Tokencachefreigabe unter iOS aktivieren.

Schützen der App selbst mit Intune

Ihre mobile App (geschrieben in Xamarin.iOS oder Xamarin. Android) kann App-Schutzrichtlinien darauf angewendet werden, sodass sie von InTune verwaltet und von Intune als verwaltete App erkannt werden können. Das InTune SDK ist von MSAL getrennt, und es wird eigenständig mit Microsoft Entra ID gesprochen.

Desktop- oder Dienstdaemon-App, die eine Web-API als sich selbst aufruft (im eigenen Namen)

Sie können eine Daemon-App schreiben, die ein Token mithilfe ihrer eigenen Identität im Vordergrund erwirbt, indem Sie die Clientanmeldeinformationen-Kaufmethoden der vertraulichen ClientclientApplication von MSAL.NET verwenden. Dies geht davon aus, dass die App zuvor einen geheimen Schlüssel (Anwendungskennwort oder Zertifikat) mit Microsoft Entra ID registriert hat, den sie dann mit diesem Aufruf teilt.

Desktop-App, die eine Web-API im Namen eines angemeldeten Benutzers aufruft

Desktopanwendungen können dieselbe interaktive Authentifizierung wie die mobilen Anwendungen verwenden.

Für Windows gehostete Anwendungen ist es auch möglich, Anwendungen, die auf Computern ausgeführt werden, die einer Windows Domäne beigetreten sind, oder Microsoft Entra, um ein Token automatisch mithilfe der integrierten Windows Authentifizierung zu erwerben.

Wenn Ihre Desktopanwendung eine .NET Core-Anwendung ist, die unter Linux oder Mac ausgeführt wird, können Sie weder den interaktiven Authentifizierungsfluss (wie .NET Core keinen Webbrowser bereitstellt) noch die integrierte Windows Authentifizierung verwenden. Die beste Option in diesem Fall ist die Verwendung des Gerätecodeflusses, wie in Der Anwendung ohne Browser erläutert, oder iOT-Anwendung, die eine API im Namen des Benutzers aufruft.

Obwohl nicht empfohlen, können Sie den Fluss "Benutzername-Kennwort " in öffentlichen Clientanwendungen verwenden. Es ist in einigen Szenarien (z. B. DevOps) noch erforderlich, aber beachten Sie, dass die Verwendung Einschränkungen für Ihre Anwendung erzwingt. So können Sie beispielsweise keine Benutzer anmelden, die mehrstufige Authentifizierung (bedingter Zugriff) ausführen müssen, oder die Vorteile des einmaligen Anmeldens (Single Sign-On, SSO) nutzen. Der Benutzername-Kennwortfluss bezieht sich auf die Prinzipien der modernen Authentifizierung und wird nur aus älteren Gründen bereitgestellt.

Wenn der Tokencache in Desktopanwendungen persistent sein soll, sollten Sie die Serialisierung des Tokencaches anpassen.

Anwendung ohne Browser oder iOT-Anwendung, die eine API im Namen des Benutzers aufruft

Anwendungen, die auf einem Gerät ohne Browser ausgeführt werden, können weiterhin eine API im Namen eines Benutzers aufrufen, nachdem der Benutzer sich auf einem anderen Gerät angemeldet hat, das über einen Webbrowser verfügt. Hierfür müssen Sie den Gerätecodefluss verwenden.

Web-API ruft eine weitere nachgeschaltete Web-API im Namen des Benutzers auf, für den er aufgerufen wurde

Wenn Ihre ASP.NET oder ASP.NET Core geschützte Web-API eine andere Web-API im Namen des Benutzers aufrufen soll, der durch das Zugriffstoken dargestellt wird, um Die API aufzurufen, müssen Sie:

• Überprüfen Sie das Token. Dafür verwenden Sie die ASP.NET JWT Middleware unter der Haube. Dies umfasst auch die Überprüfung des Tokens, das von den IdentityModel-Erweiterungen für .NET-Bibliothek durchgeführt wird, und nicht MSAL.NET
• Anschließend müssen Sie ein Token für die nachgeschaltete Web-API mithilfe der Methode "ConfidentialClientApplication" abrufen, um ein Token im Namen eines Benutzers im Dienst-zu-Dienst-Aufruf zu erwerben.
• Web-APIs, die andere Web-API aufrufen, müssen auch eine benutzerdefinierte Cache-Serialisierung bereitstellen.

Web-API, die eine andere API im eigenen Namen aufruft

Wie bei Desktop- oder Dienstdaemonanwendungen kann eine Daemon-Web-API (oder eine Daemon-Web-App) MSAL.NET Clientanmeldeinformationen-Kaufmethoden von VertraulichClientApplication verwenden.

Transverse Features

In allen Szenarien möchten Sie folgende Aktionen ausführen:

• Problembehandlung durch Aktivieren von Protokollen oder Telemetrie
• Verstehen, wie Sie auf Ausnahmen aufgrund des Microsoft Entra-Diensts MsalServiceExceptionreagieren oder auf etwas Falsches im Client selbst reagierenMsalClientException
• Verwenden von MSAL.NET mit einem Proxy