Anwendungstypen, die in Active Directory B2C verwendet werden können

2025-05-06

Von Bedeutung

Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.

Azure Active Directory B2C (Azure AD B2C) unterstützt die Authentifizierung für verschiedene moderne Anwendungsarchitekturen. Alle basieren auf den Branchenstandardprotokollen OAuth 2.0 oder OpenID Connect. In diesem Artikel werden die Arten von Anwendungen beschrieben, die Sie unabhängig von der von Ihnen gewünschten Sprache oder Plattform erstellen können. Außerdem können Sie die allgemeinen Szenarien verstehen, bevor Sie mit dem Erstellen von Anwendungen beginnen.

Jede Anwendung, die Azure AD B2C verwendet, muss mit dem Azure-Portal in Ihrem Azure AD B2C-Mandanten registriert werden. Der Anwendungsregistrierungsprozess sammelt und weist Werte zu, z. B.:

Eine Anwendungs-ID , die Ihre Anwendung eindeutig identifiziert.
Eine Antwort-URL , die verwendet werden kann, um Antworten zurück zu Ihrer Anwendung zu leiten.

Jede Anforderung, die an Azure AD B2C gesendet wird, gibt einen Benutzerfluss (eine integrierte Richtlinie) oder eine benutzerdefinierte Richtlinie an, die das Verhalten von Azure AD B2C steuert. Mit beiden Richtlinientypen können Sie eine hochgradig anpassbare Gruppe von Benutzeroberflächen erstellen.

Die Interaktion jeder Anwendung folgt einem ähnlichen allgemeinen Muster:

Die Anwendung leitet den Benutzer an den v2.0-Endpunkt weiter, um eine Richtlinie auszuführen.
Der Benutzer füllt die Richtlinie gemäß der Richtliniendefinition aus.
Die Anwendung empfängt ein Sicherheitstoken vom v2.0-Endpunkt.
Die Anwendung verwendet das Sicherheitstoken für den Zugriff auf geschützte Informationen oder eine geschützte Ressource.
Der Ressourcenserver überprüft das Sicherheitstoken, um zu überprüfen, ob der Zugriff gewährt werden kann.
Die Anwendung aktualisiert regelmäßig das Sicherheitstoken.

Diese Schritte können sich geringfügig je nach Typ der Anwendung unterscheiden, die Sie erstellen.

Webanwendungen

Für Webanwendungen (einschließlich .NET, PHP, Java, Ruby, Python und Node.js), die auf einem Webserver gehostet und über einen Browser aufgerufen werden, unterstützt Azure AD B2C OpenID Connect für alle Benutzeroberflächen. In der Azure AD B2C-Implementierung von OpenID Connect initiiert Ihre Webanwendung Benutzeroberflächen, indem Authentifizierungsanforderungen an Microsoft Entra ID gesendet werden. Das Ergebnis der Anforderung ist ein id_token. Dieses Sicherheitstoken stellt die Identität des Benutzers dar. Außerdem werden Informationen über den Benutzer in Form von Ansprüchen bereitgestellt:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Erfahren Sie mehr über die Typen von Token und Ansprüchen, die für eine Anwendung in der Azure AD B2C-Tokenreferenz verfügbar sind.

In einer Webanwendung führt jede Ausführung einer Richtlinie die folgenden allgemeinen Schritte aus:

Der Benutzer navigiert zur Webanwendung.
Die Webanwendung leitet den Benutzer an Azure AD B2C weiter, der die auszuführende Richtlinie angibt.
Der Benutzer schließt die Richtlinie ab.
Azure AD B2C gibt einen id_token an den Browser zurück.
Das id_token wird für den Umleitungs-URI bereitgestellt.
Die id_token wird validiert und ein Sitzungscookie wird festgelegt.
Eine sichere Seite wird an den Benutzer zurückgegeben.

Die Validierung der id_token mit einem von Microsoft Entra ID erhaltenen öffentlichen Signaturschlüssel reicht aus, um die Identität des Benutzers zu verifizieren. Dieser Prozess legt auch ein Sitzungscookies fest, mit dem der Benutzer auf nachfolgenden Seitenanforderungen identifiziert werden kann.

Um dieses Szenario in Aktion zu sehen, probieren Sie eines der Codebeispiele für die Webanwendungsanmeldung im Abschnitt "Erste Schritte" aus.

Zusätzlich zur Erleichterung der einfachen Anmeldung muss eine Webanwendung möglicherweise auch auf einen Back-End-Webdienst zugreifen. In diesem Fall kann die Webanwendung einen etwas anderen OpenID Connect-Fluss ausführen und Token mithilfe von Autorisierungscodes und Aktualisierungstoken abrufen. Dieses Szenario wird im folgenden Web-APIs-Abschnitt dargestellt.

Single-Page-Webanwendungen

Viele moderne Webanwendungen werden als clientseitige Einzelseitenanwendungen ("SPAs") erstellt. Entwickler schreiben sie mit JavaScript oder einem SPA-Framework wie Angular, Vue oder React. Diese Anwendungen werden in einem Webbrowser ausgeführt und weisen andere Authentifizierungsmerkmale als herkömmliche serverseitige Webanwendungen auf.

Azure AD B2C bietet zwei Optionen, um Einzelseitenanwendungen zum Anmelden von Benutzern und zum Abrufen von Token für den Zugriff auf Back-End-Dienste oder Web-APIs zu ermöglichen:

Autorisierungscodefluss (mit PKCE)

Mit dem OAuth 2.0-Autorisierungscodefluss (mit PKCE) kann die Anwendung einen Autorisierungscode für ID-Token austauschen, um die authentifizierten Benutzer und Zugriffstoken darzustellen, die zum Aufrufen geschützter APIs erforderlich sind. Darüber hinaus werden Aktualisierungstoken zurückgegeben, die langfristigen Zugriff auf Ressourcen im Auftrag von Benutzern ermöglichen, ohne dass eine Interaktion mit diesen Benutzern erforderlich ist.

Wir empfehlen diesen Ansatz. Wenn Sie Aktualisierungstoken für begrenzte Lebensdauer haben, können Sie ihre Anwendung an moderne Datenschutzbeschränkungen für Browsercookies anpassen, z. B. Safari ITP.

Um diesen Ablauf zu nutzen, kann Ihre Anwendung eine Authentifizierungsbibliothek verwenden, die ihn unterstützt, z. B. MSAL.js 2.x.

Autorisierungsfluss für Single-Page-Webanwendungen

Impliziter Gewährungsflow

Einige Bibliotheken, z. B. MSAL.js 1.x, unterstützen nur den impliziten Grant-Flow , oder Ihre Anwendung ist so implementiert, dass sie den impliziten Flow verwendet. In diesen Fällen unterstützt Azure AD B2C den impliziten OAuth 2.0-Fluss. Der Fluss für die implizite Genehmigung ermöglicht der Anwendung das Abrufen von ID- und Zugriffstoken. Im Gegensatz zum Autorisierungscodefluss gibt der implizite Genehmigungsflow kein Aktualisierungstoken zurück.

Dieser Authentifizierungsfluss umfasst keine Anwendungsszenarien, die plattformübergreifende JavaScript-Frameworks wie Electron und React-Native verwenden. Diese Szenarien erfordern weitere Funktionen für die Interaktion mit den systemeigenen Plattformen.

Warnung

Microsoft empfiehlt, dass Sie nicht den impliziten Genehmigungs-Flow verwenden. Die empfohlene Methode zur Unterstützung von SPAs ist der OAuth 2.0-Autorisierungscodefluss (mit PKCE). Bestimmte Konfigurationen dieses Flows erfordern ein sehr hohes Maß an Vertrauen in die Anwendung und bergen Risiken, die in anderen Flows nicht vorhanden sind. Verwenden Sie diesen Flow nur, wenn kein anderer Flow verfügbar ist, der mehr Sicherheit bietet. Weitere Informationen finden Sie in den Sicherheitsaspekten mit dem impliziten Genehmigungsfluss.

Web-APIs

Sie können Azure AD B2C verwenden, um Webdienste wie die RESTful-Web-API Ihrer Anwendung zu sichern. Web-APIs können OAuth 2.0 verwenden, um ihre Daten zu sichern, indem eingehende HTTP-Anforderungen mithilfe von Token authentifiziert werden. Der Aufrufer einer Web-API fügt ein Token im Autorisierungsheader einer HTTP-Anforderung an:

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

Die Web-API kann dann das Token verwenden, um die Identität des API-Aufrufers zu überprüfen und Informationen über den Aufrufer aus Ansprüchen zu extrahieren, die im Token codiert sind. Erfahren Sie mehr über die Typen von Token und Ansprüchen, die für eine App in der Azure AD B2C-Tokenreferenz verfügbar sind.

Eine Web-API kann Token von vielen Arten von Clients empfangen, darunter Webanwendungen, Desktop- und mobile Anwendungen, Einzelseitenanwendungen, serverseitige Daemons und andere Web-APIs. Hier ist ein Beispiel für den vollständigen Ablauf für eine Webanwendung, die eine Web-API aufruft:

Die Webanwendung führt eine Richtlinie aus, und der Benutzer schließt die Benutzererfahrung ab.
Azure AD B2C gibt einen (OpenID Connect) id_token und einen Autorisierungscode an den Browser zurück.
Der Browser sendet den id_token und den Autorisierungscode an den Umleitungs-URI.
Der Webserver überprüft den id_token und legt ein Sitzungscookie fest.
Der Webserver fordert von Azure AD B2C ein access_token an, indem er den Autorisierungscode, die Anwendungsclient-ID und die Clientanmeldeinformationen bereitstellt.
Die access_token und refresh_token werden an den Webserver zurückgegeben.
Die Web-API wird mit dem access_token in einem Autorisierungsheader aufgerufen.
Die Web-API überprüft das Token.
Sichere Daten werden an die Webanwendung zurückgegeben.

Weitere Informationen zu Autorisierungscodes, Aktualisierungstoken und den Schritten zum Abrufen von Token finden Sie im OAuth 2.0-Protokoll.

Informationen zum Sichern einer Web-API mithilfe von Azure AD B2C finden Sie in den Web-API-Lernprogrammen im Abschnitt "Erste Schritte".

Mobile und native Anwendungen

Anwendungen, die auf Geräten wie Mobilen und Desktopanwendungen installiert sind, müssen häufig im Auftrag von Benutzern auf Back-End-Dienste oder Web-APIs zugreifen. Mithilfe von Azure AD B2C und dem OAuth 2.0-Autorisierungscodefluss können Sie Ihren nativen Anwendungen benutzerdefinierte Identitätsverwaltungsfunktionen hinzufügen und Back-End-Dienste sicher aufrufen.

In diesem Prozess führt die Anwendung Richtlinien aus und empfängt eine authorization_code von Microsoft Entra ID, nachdem der Benutzer die Richtlinie abgeschlossen hat. Dies authorization_code stellt die Berechtigung der Anwendung dar, Back-End-Dienste im Namen des Aktuell angemeldeten Benutzers aufzurufen. Die Anwendung kann dann den authorization_code im Hintergrund für ein access_token und ein refresh_token austauschen. Die Anwendung kann access_token verwenden, um sich bei einer Back-End-Web-API in HTTP-Anforderungen zu authentifizieren. Sie kann auch refresh_token verwenden, um ein neues access_token zu erhalten, wenn ein älteres abläuft.

Daemons/serverseitige Anwendungen

Anwendungen, die lange ausgeführte Prozesse enthalten oder ohne das Vorhandensein eines Benutzers funktionieren, benötigen auch eine Möglichkeit, auf gesicherte Ressourcen wie Web-APIs zuzugreifen. Diese Anwendungen können Token authentifizieren und abrufen, indem sie ihre Identitäten (anstelle der delegierten Identität eines Benutzers) und den OAuth 2.0-Clientanmeldeinformationsfluss verwenden. Ein Client-Anmeldeinformationsfluss ist nicht gleich einem On-Behalf-Of-Fluss, und ein On-Behalf-Of-Fluss sollte nicht für die Server-zu-Server-Authentifizierung verwendet werden.

Für Azure AD B2C befindet sich der OAuth 2.0-Clientanmeldeinformationsfluss derzeit in der öffentlichen Vorschau. Sie können jedoch den Clientanmeldeinformationsfluss mithilfe der Microsoft Entra-ID und des Microsoft Identity Platform-Endpunkts /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) für eine Microsoft Graph-Anwendung oder Ihre eigene Anwendung einrichten. Weitere Informationen finden Sie im Microsoft Entra-Tokenreferenzartikel .

Nicht unterstützte Anwendungstypen

Web-API-Ketten (On-Behalf-Of-Fluss)

Viele Architekturen enthalten eine Web-API, die eine andere nachgeschaltete Web-API aufrufen muss, wobei beide durch Azure AD B2C gesichert sind. Dieses Szenario ist in systemeigenen Clients üblich, die über ein Web-API-Back-End verfügen und einen Microsoft-Onlinedienst wie die Microsoft Graph-API aufrufen.

Dieses Szenario der verketteten Web-APIs kann mithilfe der Berechtigung für Anmeldeinformationen über den OAuth 2.0-JWT-Bearer unterstützt werden, auch bekannt als On-Behalf-Of-Fluss. Der On-Behalf-Of-Fluss ist in Azure AD B2C derzeit jedoch noch nicht implementiert.

Nächste Schritte

Erfahren Sie mehr über die integrierten Richtlinien, die von Benutzerflüssen in Azure Active Directory B2C bereitgestellt werden.