Freigeben über


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.

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)

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)
Single-Page-Anwendung – Autorisierungscodeflow (mit PKCE) Single-Page-Anwendung – impliziter Flow

Eine Web-App, die einen Benutzer anmeldet

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.

Szenario Detaillierte Vorgehensweise für das Szenario OAuth 2.0-Flow und -Zuweisung Zielgruppe
Einseitige App mit Authentisierungscode Einseitige App Autorisierungscode mit PKCE Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure Active Directory B2C (Azure AD B2C)
Einseitige App mit Authentisierungscode Einseitige App Implizit Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure Active Directory B2C (Azure AD B2C)
Web-App, die Benutzer anmeldet Web-App, die Benutzer anmeldet Autorisierungscode Geschäfts-, Schul- oder Unikonten, persönliche Konten und Azure AD B2C
Web-App, die Web-APIs aufruft 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 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
Anwendungen ohne Browser App ohne Browser Gerätecode Geschäfts-, Schul- oder Unikonten, persönliche Konten, jedoch nicht Azure AD B2C
Mobile App, die Web-APIs aufruft 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 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 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
Single-Page-App Autorisierungscode
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js MSAL.js MSAL.js
MSAL.js
Einseitige App
Single-Page-App Implizit
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js
MSAL.js MSAL.js MSAL.js
MSAL.js
Web-App, die Benutzer anmeldet
Web-App, die Benutzer anmeldet
ASP.NET Core
ASP.NET Core MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core MSAL Node
MSAL Node
Web-App, die Web-APIs aufruft

Web-App, die Web-APIs aufruft
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
Flask + MSAL Python MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
Flask + MSAL Python MSAL Node
MSAL Node
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
Flask + MSAL Python MSAL Node
MSAL Node
Desktop-App, die Web-APIs aufruft

Desktop-App, die Web-APIs aufruft Gerätecodeflow
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python
MSAL Node
MSAL Node
iOS / Objective C or swift MSAL.objc
Mobile App, die Web-APIs aufruft
Mobile App, die Web-APIs aufruft
UWP MSAL.NET Xamarin MSAL.NET iOS / Objective C or swift MSAL.objc Android MSAL.Android
Daemon-App
Daemon-App
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NETMSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
Web-API, die Web-APIs aufruft

Web-API, die Web-APIs aufruft
ASP.NET Core
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NET
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node
.NET
ASP.NET Core + MSAL.NET MSAL Java
MSAL Java
MSAL Python
MSAL Python MSAL Node
MSAL Node

Weitere Informationen finden Sie unter Microsoft Identity Platform-Authentifizierungsbibliotheken.

Nächste Schritte

Weitere Informationen zur Authentifizierung finden Sie unter: