Microsoft Identity Platform-Apparten und Authentifizierungsabläufe

Artikel
03/20/2024

Microsoft Identity Platform unterstützt die Authentifizierung für verschiedene Arten moderner Anwendungsarchitekturen. Diese Architekturen basieren jeweils auf den branchenüblichen Protokollen OAuth 2.0 und OpenID Connect. Durch die Verwendung der Authentifizierungsbibliotheken für die Microsoft Identity Platform authentifizieren Anwendungen die Identitäten und rufen Token für den Zugriff auf geschützte APIs ab.

In diesem Artikel werden Authentifizierungsflows und Anwendungsszenarien beschrieben, in denen sie verwendet werden.

Anwendungskategorien

Sicherkeitstoken können von verschiedenen Arten von Anwendungen abgerufen werden. Hierzu zählen:

Web-Apps
Mobile Apps
Desktop-Apps
Web-APIs

Token können auch von Apps auf Geräten abgerufen werden, die keinen Browser aufweisen oder als IoT-Geräte (Internet of Things, Internet der Dinge) verwendet werden.

In den folgenden Abschnitten werden die Anwendungskategorien beschrieben.

Geschützte Ressourcen oder Clientanwendungen

Die Authentifizierungsszenarien beinhalten zwei Aktivitäten:

Abrufen von Sicherheitstoken für eine geschützte Web-API: Wir empfehlen, die von Microsoft entwickelte und unterstützte Microsoft Authentication Library (MSAL) zu verwenden.
Schützen einer Web-API oder einer Web-App: Eine der Herausforderungen beim Schutz dieser Ressourcen besteht in der Überprüfung des Sicherheitstokens. Für einige Plattformen bietet Microsoft Middlewarebibliotheken an.

Mit Benutzern oder ohne Benutzer

In den meisten Authentifizierungsszenarien werden Token im Namen angemeldeter Benutzer abgerufen.

Szenarien mit Benutzern

Es sind jedoch auch Daemon-Apps vorhanden. In diesen Szenarien rufen Anwendungen Token für sich selbst (also ohne Benutzer) ab.

Szenarien mit Daemon-Apps

Single-Page-Webanwendungen, öffentliche Clientanwendungen und vertrauliche Clientanwendungen

Sicherheitstoken können von verschiedenen Arten von Anwendungen abgerufen werden. Diese Anwendungen werden in der Regel in die folgenden drei Kategorien unterteilt. Jede wird mit unterschiedlichen Bibliotheken und Objekten verwendet.

Single-Page-Webanwendungen: Bei diesen auch als SPAs bezeichneten Web-Apps werden Token über eine im Browser ausgeführte JavaScript- oder TypeScript-App abgerufen. Viele moderne Apps verfügen über eine Single-Page-Webanwendung am Front-End, die hauptsächlich in JavaScript geschrieben ist. Die Anwendung nutzt häufig ein Framework wie Angular, React oder Vue. MSAL.js ist die einzige Microsoft Authentication Library, die Single-Page-Anwendungen unterstützt.
Öffentliche Clientanwendungen: Mit Apps in dieser Kategorie, beispielsweise den folgenden Arten, werden Benutzer immer angemeldet:
- Desktop-Apps, die Web-APIs im Namen angemeldeter Benutzer aufrufen
- Mobile Apps
- Apps, die auf Geräten ohne Browser ausgeführt werden (etwa IoT-Geräte)
Vertrauliche Clientanwendungen: Apps in dieser Kategorie umfassen:
- Web-Apps, die eine Web-API aufrufen
- Web-APIs, die eine Web-API aufrufen
- Daemon-Apps (auch bei Implementierung als Konsolendienst – etwa im Falle eines Linux-Daemons oder eines Windows-Diensts)

Die verfügbaren Authentifizierungsflows hängen von der Zielgruppe für die Anmeldung ab. Einige Flows stehen nur für Geschäfts-, Schul- oder Unikonten zur Verfügung. Andere sind sowohl für Geschäfts-, Schul- oder Unikonten als auch für persönliche Microsoft-Konten verfügbar.

Weitere Informationen finden Sie unter Unterstützte Kontotypen.

Anwendungstypen

Microsoft Identity Platform unterstützt die Authentifizierung für folgende App-Architekturen:

Single-Page-Apps
Web-Apps
Web-APIs
Mobile Apps
Native Apps
Daemon-Apps
Serverseitige Apps

Anwendungen verwenden die verschiedenen Authentifizierungsflows, um Benutzer anzumelden und Token für den Aufruf geschützter APIs zu beziehen.

Einseitige Anwendung

Viele moderne Web-Apps werden als clientseitige Single-Page-Anwendungen (SPAs) erstellt. Diese Anwendungen verwenden JavaScript oder ein Framework wie Angular, Vue und React. Diese Anwendungen werden in einem Webbrowser ausgeführt.

Single-Page-Webanwendungen unterscheiden sich im Hinblick auf die Authentifizierungsmerkmale von herkömmlichen serverseitigen Web-Apps. Durch die Nutzung von Microsoft Identity Platform können Single-Page-Webanwendungen Benutzer anmelden und Token für den Zugriff auf Back-End-Dienste oder Web-APIs beziehen. Microsoft Identity Platform bietet zwei Gewährungstypen für JavaScript-Anwendungen:

MSAL.js (2.x)	MSAL.js (1.x)

Eine Web-App, die einen Benutzer anmeldet

So schützen Sie eine Web-App, die einen Benutzer anmeldet:

.NET-Entwickler verwenden ASP.NET oder ASP.NET Core mit OpenID Connect-Middleware für ASP.NET. Der Schutz einer Ressource beinhaltet die Überprüfung des Sicherheitstokens. Diese erfolgt nicht durch MSAL-Bibliotheken, sondern durch die IdentityModel-Erweiterungen für .NET.
Node.js-Entwickler verwenden MSAL Node.

Weitere Informationen finden Sie unter Szenario: Web-App, die Benutzer anmeldet.

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

Eine Web-App, die Web-APIs aufruft

Um eine Web-API über eine Web-App im Namen eines Benutzers aufzurufen, verwenden Sie den Autorisierungscodeflow und speichern die abgerufenen Token im Tokencache. Bei Bedarf werden Token von MSAL aktualisiert, und der Controller ruft automatisch Token aus dem Cache ab.

Weitere Informationen finden Sie unter Web-App, die Web-APIs aufruft.

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

Wenn eine Desktop-App eine Web-API für die Benutzeranmeldung aufrufen soll, verwenden Sie die interaktiven Tokenabrufmethoden von MSAL. Mit diesen interaktiven Methoden können Sie die Benutzeroberfläche für die Anmeldeumgebung steuern. MSAL verwendet für diese Interaktion einen Webbrowser.

Eine Desktop-App, die eine Web-API aufruft

Für von Windows gehostete Anwendungen auf Computern, die einer Windows-Domäne angehören oder über Microsoft Entra ID miteinander verknüpft sind, gibt es noch eine weitere Möglichkeit. Diese Anwendungen können unter Verwendung der integrierten Windows-Authentifizierung automatisch ein Token abrufen.

Anwendungen, die auf einem Gerät ohne Browser ausgeführt werden, können weiterhin eine API im Namen eines Benutzers aufrufen. Zur Authentifizierung muss sich der Benutzer auf einem anderen Gerät mit Webbrowser anmelden. In diesem Szenario muss der Gerätecodeflow verwendet werden.

Gerätecodefluss

Für öffentliche Clientanwendungen steht zwar auch der Benutzername/Kennwort-Flow zur Verfügung, allerdings wird von der Verwendung abgeraten. Er wird beispielsweise in DevOps-Szenarien benötigt.

Wenn Sie den Benutzername/Kennwort-Flow verwenden, werden Ihre Anwendungen eingeschränkt. Anwendungen können beispielsweise keine Benutzer*innen anmelden, die eine Multi-Faktor-Authentifizierung oder das Tool für bedingten Zugriff in Microsoft Entra ID verwenden müssen. Auch einmaliges Anmelden steht für Ihre Anwendungen nicht zur Verfügung. Die Authentifizierung mit dem Benutzername/Kennwort-Flow widerspricht den Prinzipien der modernen Authentifizierung und wird lediglich aus Legacygründen bereitgestellt.

Wenn Sie in Desktop-Apps den Tokencache dauerhaft beibehalten möchten, können Sie die Serialisierung des Tokencaches anpassen. Die Implementierung einer dualen Tokencacheserialisierung ermöglicht die Verwendung abwärts- und aufwärtskompatibler Tokencaches.

Weitere Informationen finden Sie unter Szenario: Desktop-App, die Web-APIs aufruft.

Mobile App, die eine Web-API im Namen eines interaktiven Benutzers aufruft

Eine mobile App ruft ähnlich wie eine Desktop-App die interaktiven Tokenabrufmethoden von MSAL auf, um ein Token für den Aufruf einer Web-API abzurufen.

Eine mobile App, die eine Web-API aufruft

MSAL iOS und MSAL Android verwenden standardmäßig den Webbrowser des Systems. Sie können jedoch auch festlegen, dass stattdessen die eingebettete Webansicht verwendet werden soll. Es gibt bestimmte Besonderheiten für die jeweilige mobile Plattform: universelle Windows-Plattform (UWP), iOS oder Android.

In einigen Szenarien (beispielsweise bei bedingtem Zugriff im Zusammenhang mit einer Geräte-ID oder Geräteregistrierung) muss ein Broker auf dem Gerät installiert sein. Beispiele für Broker sind das Microsoft-Unternehmensportal (Android) und Microsoft Authenticator (Android und iOS).

Weitere Informationen finden Sie unter Szenario: Mobile App, die Web-APIs aufruft.

Hinweis

Auf eine mobile App, die MSAL iOS oder MSAL Android verwendet, können App-Schutzrichtlinien angewendet werden. Mit diesen Richtlinien kann beispielsweise verhindert werden, dass ein Benutzer geschützten Text kopiert. Die mobile App wird von Intune verwaltet und als verwaltete App erkannt. Weitere Informationen finden Sie in der Übersicht zum Microsoft Intune App SDK.

Das Intune App SDK ist von den MSAL-Bibliotheken getrennt und interagiert eigenständig mit Microsoft Entra ID.

Geschützte Web-API

Mit dem Microsoft Identity Plattform-Endpunkt können Sie Webdienste wie etwa die RESTful-API Ihrer App schützen. Eine geschützte Web-API wird über ein Zugriffstoken aufgerufen. Das Token schützt die Daten der API und authentifiziert eingehende Anforderungen. Der Aufrufer einer Web-API fügt an den Autorisierungsheader einer HTTP-Anforderung ein Zugriffstoken an.

Validieren Sie das Zugriffstoken, wenn Sie Ihre ASP.NET- oder ASP.NET Core-Web-API schützen möchten. Für diese Validierung wird die JWT-Middleware für ASP.NET verwendet. Die Validierung wird nicht von MSAL.NET, sondern von der Bibliothek IdentityModel-Erweiterungen für .NET durchgeführt.

Weitere Informationen finden Sie unter Szenario: Geschützte Web-API.

Web-API, die eine andere Web-API im Namen eines Benutzers aufruft

Damit Ihre geschützte Web-API eine andere Web-API im Namen eines Benutzers aufrufen kann, muss Ihre App ein Token für die Downstream-Web-API abrufen. Solche Aufrufe werden manchmal auch als Dienst-zu-Dienst-Aufrufe bezeichnet. Web-APIs, die andere Web-APIs aufrufen, müssen auch eine benutzerdefinierte Cacheserialisierung bereitstellen.

Eine Web-API, die eine andere Web-API aufruft

Weitere Informationen finden Sie unter Szenario: Web-API, die Web-APIs aufruft.

Daemon-App, die eine Web-API im Namen des Daemons aufruft

Apps, die Prozesse mit langer Ausführungszeit enthalten oder ohne Benutzerinteraktion ausgeführt werden, benötigen ebenfalls eine Möglichkeit, um auf sichere Web-APIs zuzugreifen. Eine solche App kann sich mithilfe der App-Identität authentifizieren und Token abrufen. Die App weist ihre Identität mit einem geheimen Clientschlüssel oder einem Zertifikat nach.

Wenn Sie solche Daemon-Apps schreiben möchten, die ein Token für die aufrufende App abrufen, verwenden Sie die Abrufmethoden für Clientanmeldeinformationen in MSAL. Diese Methoden erfordern einen geheimen Clientschlüssel, den Sie der App-Registrierung in Microsoft Entra ID hinzufügen. Die App gibt das Geheimnis dann an den aufgerufenen Daemon weiter. Beispiele für solche Geheimnisse wären etwa Anwendungskennwörter, Zertifikatassertionen und Clientassertionen.

Eine von anderen Apps und APIs aufgerufene Daemon-App

Weitere Informationen finden Sie unter Szenario: Daemon-App zum Aufrufen von Web-APIs.

Szenarien und unterstützte Authentifizierungsflows

Sie verwenden Authentifizierungsflows zur Implementierung der Anwendungsszenarien mit Tokenanforderung. Anwendungsszenarien und Authentifizierungsflows lassen sich nicht eins zu eins zuordnen.

Szenarien mit Tokenabruf werden auch OAuth 2.0-Authentifizierungsflows zugeordnet. Weitere Informationen finden Sie unter OAuth 2.0 und OpenID Connect-Protokolle auf der Microsoft Identity Platform.

Detaillierte Vorgehensweise für das Szenario	OAuth 2.0-Flow und -Zuweisung	Zielgruppe
Einseitige App	Autorisierungscode mit PKCE	Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure Active Directory B2C (Azure AD B2C)
Einseitige App	Implizit	Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure Active Directory B2C (Azure AD B2C)
Web-App, die Benutzer anmeldet	Autorisierungscode	Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure AD B2C
Web-App, die Web-APIs aufruft	Autorisierungscode	Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure AD B2C
Desktop-App, die Web-APIs aufruft	Interaktiv unter Verwendung eines Autorisierungscodes mit PKCE	Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure AD B2C
	Integrierte Windows-Authentifizierung	Geschäfts-, Schul- oder Unikonten
	Kennwort des Ressourcenbesitzers	Geschäfts-, Schul- oder Unikonten und Azure AD B2C
App ohne Browser	Gerätecode	Geschäfts-, Schul- oder Unikonten, persönliche Konten, jedoch nicht Azure AD B2C
Mobile App, die Web-APIs aufruft	Interaktiv unter Verwendung eines Autorisierungscodes mit PKCE	Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure AD B2C
	Kennwort des Ressourcenbesitzers	Geschäfts-, Schul- oder Unikonten und Azure AD B2C
Daemon-App, die Web-APIs aufruft	Clientanmeldeinformationen	Reine App-Berechtigungen ohne Benutzer*innen, die ausschließlich in Microsoft Entra-Organisationen verwendet werden
Web-API, die Web-APIs aufruft	OBO (On-Behalf-Of)	Geschäfts-, Schul- oder Unikonten und persönliche Konten

Szenarien und unterstützte Plattformen und Sprachen

Die Microsoft-Authentifizierungsbibliotheken unterstützen mehrere Plattformen:

.NET
.NET Framework
Java
JavaScript
macOS
Natives Android
Natives iOS
Node.js
Python
Windows 10/UWP

Sie können zum Erstellen Ihrer Anwendungen auch verschiedene Sprachen verwenden.

Wenn in der Windows-Spalte der folgenden Tabelle .NET angegeben ist, ist immer auch .NET Framework möglich. Letzteres wurde zur besseren Übersichtlichkeit der Tabelle weggelassen.

Szenario	Windows	Linux	Mac	iOS	Android
Einseitige App	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Einseitige App	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Web-App, die Benutzer anmeldet	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node
Web-App, die Web-APIs aufruft	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node
Desktop-App, die Web-APIs aufruft	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node MSAL.objc
Mobile App, die Web-APIs aufruft	MSAL.NET MSAL.NET			MSAL.objc	MSAL.Android
Daemon-App	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node
Web-API, die Web-APIs aufruft	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node