Microsoft Identity Platform-Apparten und Authentifizierungsabläufe

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.

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

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)

Zielgruppe für die Anmeldung

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

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.

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.

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.

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). MSAL kann jetzt mit Brokern interagieren. Weitere Informationen zu Brokern finden Sie unter Nutzen von Brokern unter Android und iOS.

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

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.

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.

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.

Szenario	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
	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
• Xamarin.iOS
• Xamarin.Android

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

Weitere Informationen finden Sie unter Microsoft Identity Platform-Authentifizierungsbibliotheken.

Nächste Schritte

Weitere Informationen zur Authentifizierung finden Sie unter:

• Authentifizierung im Vergleich zu Autorisierung
• Microsoft Identity Platform-Zugriffstoken
• Sichern des Zugriffs auf IoT-Apps