Anwendungstypen für die Microsoft Identity Platform

Die Microsoft Identity Platform unterstützt die Authentifizierung für unterschiedliche moderne App-Architekturen, die alle auf den branchenüblichen Standardprotokollen OAuth 2.0 oder OpenID Connect basieren. Dieser Artikel beschreibt die App-Typen, die Sie unabhängig von der bevorzugten Sprache oder Plattform mithilfe von Microsoft Identity Platform erstellen können. Die Informationen dienen Ihrem Verständnis allgemeiner Szenarien, bevor Sie beginnen, in den Anwendungsszenarios mit Code zu arbeiten.

Grundlagen

Sie müssen jede App, die die Microsoft Identity Platform verwendet, im Microsoft Entra Admin Center in App-Registrierungen registrieren. Beim App-Registrierungsvorgang werden die folgenden Werte für die App erfasst und zugewiesen:

• Eine Anwendungs- (bzw. Client-) ID, die Ihre App eindeutig identifiziert
• Ein Umleitungs-URI, der zum Umleiten von Antworten zurück an die App verwendet werden kann
• Einige andere szenariospezifische Werte, wie z.B. unterstützte Kontotypen

Nähere Informationen finden Sie im Artikel zum Registrieren einer App.

Nach der Registrierung der App erfolgt die Kommunikation zwischen der App und der Microsoft Identity Plattform durch Senden von Anforderungen an den Endpunkt. Wir stellen Open-Source-Frameworks und -Bibliotheken bereit, über die die Details dieser Anforderungen verarbeitet werden. Zudem können Sie auch selbst die Authentifizierungslogik implementieren, indem Sie Anforderungen an diese Endpunkte erstellen:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Die von der Microsoft Identity Platform unterstützten App-Typen sind:

• Single-Page-Webanwendung (Single-Page-App, SPA)
• Web-App
• Web-API
• Mobile und native Apps
• Dienst, Daemon, Skript

Single-Page-Apps

Viele moderne Apps verfügen über ein Single-Page-Webanwendungs (SPA)-Front-End, das in erster Linie in JavaScript geschrieben ist, häufig mit einem Framework wie Angular, React oder Vue. Die Microsoft Identity Platform unterstützt diese Apps mithilfe des OpenID Connect-Protokolls für die Authentifizierung und einem von zwei Autorisierungsgewährungstypen, die von OAuth 2.0 definiert werden. Die unterstützten Gewährungstypen sind entweder der implizite OAuth 2.0-Gewährungsflow oder der neuere OAuth 2.0-Autorisierungscode+PKCE-Flow (siehe unten).

Das Flussdiagramm veranschaulicht den OAuth 2.0-Autorisierungscode-Genehmigungsflow (ohne Details zu PKCE), bei der die App einen Code vom Endpunkt authorize der Microsoft Identity Platform erhält und diesen gegen ein Zugriffstoken und ein Aktualisierungstoken unter Verwendung von standortübergreifenden Webanforderungen einlöst. Bei SPAs ist das Zugriffstoken 1 Stunde lang gültig, und nach Ablauf muss ein anderer Code über das Aktualisierungstoken angefordert werden. Zusätzlich zum Zugriffstoken wird normalerweise über denselben Flow und/oder eine separate OpenID Connect-Anforderung (hier nicht dargestellt) auch ein id_token angefordert, das den bei der Clientanwendung angemeldeten Benutzer repräsentiert.

Informationen hierzu finden Sie im Schnellstart: Anmelden von Benutzer*innen in einer Single-Page-Webanwendung (SPA) und Aufrufen der Microsoft Graph-API mithilfe von JavaScript.

Autorisierungscodeflow im Vergleich zum impliziten Fluss

Der OAuth 2.0-Autorisierungscodeflow ist jetzt die empfohlene Methode zum Erstellen von SPAs, um die Kompatibilität Ihrer App in Safari und anderen datenschutzfreundliche Browsern sicherzustellen. Nach der Entfernung von Cookies von Drittanbietern und größerer Aufmerksamkeit wird die Verwendung des impliziten Flows nicht länger empfohlen.

Web-Apps

Bei Web-Apps (.NET, PHP, Java, Ruby, Python, Node), auf die der Benutzer über einen Browser zugreift, können Sie für die Benutzeranmeldung OpenID Connect verwenden. In OpenID Connect empfängt die Web-App ein ID-Token. Ein ID-Token ist ein Sicherheitstoken, das die Identität des Benutzers überprüft und Informationen über den Benutzer in Form von Ansprüchen enthält:

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "ab12cd34-effe-5678-9012-abcdef012345"
    ...
}

Weitere Informationen zu verschiedenen Tokentypen, die in der Microsoft Identity Plattform verwendet werden, finden Sie in der Referenz zu Zugriffstoken und zu id_token.

In Webserver-Apps werden beim Authentifizierungsablauf für die Anmeldung folgende allgemeine Schritte ausgeführt:

Sie können die Identität des Benutzers validieren, indem Sie das ID-Token mit einem öffentlichen Signaturschlüssel überprüfen, der von der Microsoft Identity Plattform empfangen wird. Ein Sitzungscookie wird festgelegt, das zur Identifizierung des Benutzers in nachfolgenden Seitenanforderungen verwendet werden kann.

Erfahren Sie mehr, indem Sie in der folgenden mehrteiligen Tutorialreihe eine ASP.NET Core-Webanwendung für die Anmeldung von Benutzern erstellen

Neben der einfachen Anmeldung benötigt eine Webserver-App möglicherweise Zugriff auf einen anderen Webdienst, z. B. auf eine REST-API (Representational State Transfer). In diesem Fall wird die Webserver-App in einem kombinierten OpenID Connect- und OAuth 2.0-Vorgang ausgeführt, indem der OAuth 2.0-Autorisierungscodefluss verwendet wird. Weitere Informationen zu diesem Szenario finden Sie in unserem Codebeispiel.

Web-APIs

Mit der Microsoft Identity Plattform können Sie Webdienste schützen, z. B. die RESTful-Web-API Ihrer App. Web-APIs können auf zahlreichen Plattformen und in vielen Sprachen implementiert werden. Sie können auch mithilfe von HTTP-Triggern in Azure Functions implementiert werden. Anstelle von ID-Token und Sitzungscookies verwendet eine Web-API ein OAuth 2.0-Zugriffstoken zum Schutz der zugehörigen Daten und zum Authentifizieren eingehender Anforderungen.

Der Aufrufer einer Web-API fügt ein Zugriffstoken wie folgt im Autorisierungsheader einer HTTP-Anforderung an:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
Accept: application/json
...

Die Web-API verwendet das Zugriffstoken zum Überprüfen der Identität des API-Aufrufers und zum Extrahieren von Informationen über den Aufrufer aus Ansprüchen, die im Zugriffstoken codiert sind. Weitere Informationen zu verschiedenen Tokentypen, die in der Microsoft Identity Plattform verwendet werden, finden Sie in der Referenz zu Zugriffstoken und zu ID-Token.

Eine Web-API kann Benutzern die Möglichkeit geben, sich für oder gegen bestimmte Funktionen oder Daten zu entscheiden, indem sie Berechtigungen erhalten, die auch Bereiche genannt werden. Damit eine aufrufende App Berechtigungen für einen Bereich erhält, muss der Benutzer während eines Ablaufs seine Zustimmung für den Bereich erteilen. Die Microsoft Identity Plattform fragt die Zustimmung des Benutzers ab und zeichnet dann die Berechtigungen in allen Zugriffstoken auf, die die Web-API empfängt. Die Web-API überprüft das Zugriffstoken, das bei jedem Aufruf empfangen wird, und führt Autorisierungsprüfungen durch.

Eine Web-API kann Zugriffstoken von allen App-Typen empfangen, z. B. von Webserver-Apps, Desktop-Apps, mobilen Apps, Single Page-Apps, serverseitigen Daemons und selbst von anderen Web-APIs. Der allgemeine Ablauf für eine Web-API sieht folgendermaßen aus:

Informationen zum Sichern einer Web-API mithilfe von OAuth2-Zugriffstoken finden Sie in den Web-API-Codebeispielen im Tutorial „Geschützte Web-API“.

Oftmals müssen Web-APIs auch ausgehende Anforderungen an nachgelagerte Web-APIs stellen, die von Microsoft Identity Plattform geschützt werden. Zu diesem Zweck können Web-APIs den On-Behalf-Of (OBO)-Flow nutzen, der der Web-API ermöglicht, ein eingehendes Zugriffstoken gegen ein anderes Zugriffstoken zu tauschen, das in ausgehenden Anforderungen verwendet werden soll. Weitere Informationen finden Sie unter Microsoft Identity Plattform und On-Behalf-Of-Fluss in OAuth 2.0.

Mobile und native Apps

Auf Geräten installierte Apps, z. B. mobile Apps und Desktop-Apps, benötigen häufig Zugriff auf Back-End-Dienste oder Web-APIs, die im Auftrag eines Benutzers Daten speichern und Funktionen ausführen. Diese Apps können sich mithilfe des OAuth 2.0-Autorisierungscodeflusses bei Back-End-Diensten anmelden und die Autorisierung hinzufügen.

Bei diesem Fluss empfängt die App bei der Anmeldung des Benutzers von der Microsoft Identity Platform einen Autorisierungscode. Der Autorisierungscode stellt die Berechtigung der App zum Aufrufen von Back-End-Diensten im Namen des angemeldeten Benutzers dar. Die App kann den Autorisierungscode im Hintergrund gegen ein OAuth 2.0-Zugriffstoken und ein Aktualisierungstoken austauschen. Die App kann mithilfe des Zugriffstokens Web-APIs in HTTP-Anforderungen authentifizieren und mithilfe des Aktualisierungstokens neue Zugriffstoken abrufen, wenn die älteren Zugriffstoken abgelaufen sind.

Hinweis

Wenn die Anwendung die Standardsystemwebansicht verwendet, überprüfen Sie die Informationen zur Funktion „Meine Anmeldung bestätigen“ und den Fehlercode AADSTS50199 in Fehlercodes bei der Microsoft Entra-Authentifizierung und -Autorisierung.

Server, Daemons und Skripts

Apps, die Prozesse mit langer Ausführungsdauer umfassen oder ohne Benutzereingriff ausgeführt werden, benötigen auch die Möglichkeit, auf sichere Ressourcen wie Web-APIs zuzugreifen. Diese Apps können mithilfe der App-Identität (anstelle der delegierten Benutzeridentität) über den OAuth 2.0-Ablauf für Clientanmeldeinformationen die Authentifizierung durchführen und Token abrufen. Sie können die Identität der App mit einem geheimen Clientschlüssel oder einem Zertifikat nachweisen. Weitere Informationen finden Sie unter .NET-Daemon-Konsolenanwendung mit Microsoft Identity Platform.

In diesem Flow interagiert die App direkt mit dem /token-Endpunkt, um Zugriff zu erhalten:

Informationen zum Erstellen einer Daemon-App finden Sie in der Dokumentation zu Clientanmeldeinformationen. Sie können aber auch eine .NET-Beispiel-App testen.

Siehe auch

Nachdem Sie nun mit den von der Microsoft Identity Platform unterstützten Anwendungstypen vertraut sind, informieren Sie sich über OAuth 2.0 und OpenID Connect, um ein besseres Verständnis der in den verschiedenen Szenarien verwendeten Protokollkomponenten zu entwickeln.