Teilen über

In Active Directory B2C verwendbare Anwendungstypen

  • Artikel

Azure Active Directory B2C (Azure AD B2C) unterstützt die Authentifizierung für verschiedenste moderne Anwendungsarchitekturen. Diese basieren alle auf den branchenüblichen Protokollen OAuth 2.0 oder OpenID Connect. In diesem Artikel werden die Anwendungstypen beschrieben, die Sie unabhängig von der bevorzugten Sprache oder Plattform erstellen können. Außerdem verdeutlicht es die allgemeinen Szenarios, bevor Sie mit dem Erstellen von Anwendungen beginnen.

Jede Anwendung, die Azure AD B2C verwendet, muss über das Azure-Portal in Ihrem Azure AD B2C-Mandanten registriert werden. Während des Anwendungsregistrierungsprozesses werden Werte erfasst und zugewiesen, wie z.B.:

  • Eine Anwendungs-ID, die Ihre Anwendung eindeutig ausweist.
  • Ein Antwort-URI, der zum Umleiten von Antworten zurück an die Anwendung verwendet werden kann.

Jede an Azure AD B2C gesendete Anforderung gibt einen Benutzerflow (eine integrierte Richtlinie) oder eine benutzerdefinierte Richtlinie an, die das Verhalten von Azure AD B2C steuert. Beide Richtlinientypen ermöglichen die Erstellung hochgradig anpassbarer Benutzerumgebungen.

Die Interaktion der einzelnen Anwendungen folgt einem ähnlichen allgemeinen Muster:

  1. Die Anwendung leitet den Endbenutzer an den v2.0-Endpunkt weiter, um eine Richtlinie auszuführen.
  2. Der Benutzer schließt die Richtlinie gemäß Richtliniendefinition ab.
  3. Die Anwendung empfängt ein Sicherheitstoken vom v2.0-Endpunkt.
  4. Die Anwendung verwendet das Sicherheitstoken für den Zugriff auf geschützte Informationen oder eine geschützte Ressource.
  5. Der Ressourcenserver überprüft das Sicherheitstoken, um sicherzustellen, dass der Zugriff gewährt werden kann.
  6. Die Anwendung aktualisiert das Sicherheitstoken in regelmäßigen Abständen.

Diese Schritte können sich je nach erstelltem Anwendungstyp geringfügig unterscheiden.

Webanwendungen

Für auf einem Webserver gehostete Webanwendungen (einschließlich .NET, PHP, Java, Ruby, Python und Node.js), auf die über einen Browser zugegriffen werden kann, 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 für Microsoft Entra ID ausgegeben werden. Das Ergebnis der Anforderung ist ein id_token. Dieses Sicherheitstoken stellt die Identität des Benutzers dar. Darüber hinaus 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": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Informationen zu allen Arten von Token und zu den für eine Anwendung verfügbaren Ansprüchen finden Sie in der Azure AD B2C-Tokenreferenz.

In einer Webanwendung sind für jede Ausführung einer Richtlinie im Allgemeinen folgende Schritte erforderlich:

  1. Der Benutzer durchsucht die Webanwendung.
  2. Die Webanwendung leitet den Benutzer an Azure AD B2C um und gibt die auszuführende Richtlinie an.
  3. Der Benutzer schließt die Richtlinie ab.
  4. Azure AD B2C gibt ein id_token an den Browser zurück.
  5. Das id_token wird für den Umleitungs-URI bereitgestellt.
  6. Das id_token wird überprüft, und ein Sitzungscookie wird festgelegt.
  7. Für den Benutzer wird eine sichere Seite zurückgegeben.

Die Überprüfung von id_token mithilfe eines von Microsoft Entra ID erhaltenen öffentlichen Signaturschlüssels ist ausreichend, um die Identität des Benutzers zu bestätigen. Bei diesem Prozess wird auch ein Sitzungscookie festgelegt, das zur Identifizierung des Benutzers in nachfolgenden Seitenanforderungen verwendet werden kann.

Um dieses Szenario in Aktion zu sehen, können Sie eines der Webanwendungs-Codebeispiele für die Anmeldung im Abschnitt Erste Schritte testen.

Neben der Bereitstellung der einfachen Anmeldung benötigt eine Webanwendung möglicherweise auch Zugriff auf einen Back-End-Webdienst. In diesem Fall kann die Webanwendung einen etwas anderen OpenID Connect-Ablauf durchführen und Token anhand von Autorisierungscodes und Aktualisierungstoken beschaffen. Dieses Szenario ist im folgenden Abschnitt zu Web-APIsdargestellt.

Single-Page-Webanwendungen

Viele moderne Webanwendungen werden als clientseitige Single-Page-Webanwendungen („SPAs“) erstellt. Entwickler schreiben diese mithilfe von JavaScript oder eines SPA-Frameworks 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 Single-Page-Webanwendungen das Anmelden von Benutzern und Abrufen von Token für den Zugriff auf Back-End-Dienste oder -Web-APIs zu ermöglichen:

Autorisierungscodefluss (mit PKCE)

Der OAuth 2.0-Autorisierungscodeflow (mit PKCE) ermöglicht der Anwendung, einen Autorisierungscode für ID-Token auszutauschen, um die authentifizierten Benutzer*innen darzustellen, sowie Zugriffstoken auszutauschen, die zum Aufrufen geschützter APIs erforderlich sind. Darüber hinaus werden Aktualisierungstoken zurückgegeben, die langfristigen Zugriff auf Ressourcen im Auftrag von Benutzern bereitstellen, ohne dass eine Interaktion mit diesen Benutzern erforderlich ist.

Dieser Ansatz wurde empfohlen. Aktualisierungstoken mit begrenzter Lebensdauer tragen zur Anpassung Ihrer Anwendung an die in Bezug auf die Einschränkungen von Cookies geltenden Datenschutzbestimmungen moderner Browser (z. B. an Safari ITP) bei.

Um diesen Fluss nutzen zu können, kann Ihre Anwendung eine Authentifizierungsbibliothek verwenden, von der sie unterstützt wird, z. B. MSAL.js 2.x.

Autorisierungsfluss für Single-Page-Webanwendungen

Impliziter Gewährungsflow

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

Dieser Ansatz ist nicht zu empfehlen.

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

Web-APIs

Sie können Azure AD B2C zum Schützen von Webdiensten, wie z.B. der RESTful-Web-API Ihrer Anwendung, verwenden. Web-APIs können OAuth 2.0 verwenden, um ihre Daten zu schützen, indem eingehende HTTP-Anforderungen per 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 mit dem Token die Identität des API-Aufrufers überprüfen und Informationen über den Aufrufer aus Ansprüchen extrahieren, die im Token codiert sind. Informationen zu allen Arten von Token und zu den für eine App verfügbaren Ansprüchen finden Sie in der Azure AD B2C-Tokenreferenz.

Eine Web-API kann Token von vielen Clienttypen empfangen, einschließlich Webanwendungen, Desktop- und mobilen Anwendungen, Single-Page-Anwendungen, serverseitigen Daemons und anderen Web-APIs. Hier sehen Sie ein Beispiel für den vollständigen Ablauf für eine Webanwendung, die eine Web-API aufruft:

  1. Die Webanwendung führt eine Richtlinie aus, und der Benutzer schließt die Benutzeroberfläche ab.
  2. Azure AD B2C gibt id_token (OpenID Connect) und einen Autorisierungscode an den Browser zurück.
  3. Der Browser stellt das id_token und den Autorisierungscode für den Umleitungs-URI bereit.
  4. Der Webserver überprüft das id_token und legt ein Sitzungscookie fest.
  5. Der Webserver fragt Azure AD B2C nach access_token. Dabei gibt er den Autorisierungscode, die Anwendungsclient-ID sowie Clientanmeldeinformationen an.
  6. Das access_token und das refresh_token werden an den Webserver zurückgegeben.
  7. Die Web-API wird mit dem access_token in einem Autorisierungsheader aufgerufen.
  8. Die Web-API überprüft das Token.
  9. 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.

Weitere Informationen zum Schützen einer Web-API mit Azure AD B2C finden Sie in den Tutorials zur Web-API im Abschnitt mit den ersten Schritten.

Mobile und native Anwendungen

Auf Geräten installierte Anwendungen, z.B. mobile Anwendungen und Desktopanwendungen, benötigen häufig Zugriff auf Back-End-Dienste oder Web-APIs im Auftrag von Benutzern. Sie können Ihren nativen Anwendungen angepasste Oberflächen für die Identitätsverwaltung hinzufügen und Back-End-Dienste sicher aufrufen, indem Sie Azure AD B2C und den Autorisierungscodeablauf von OAuth 2.0 verwenden.

Bei diesem Ablauf führt die Anwendung Richtlinien aus und empfängt einen authorization_code von Microsoft Entra ID, nachdem der Benutzer die Richtlinie abgeschlossen hat. Der authorization_code stellt die Berechtigung der Anwendung zum Aufrufen von Back-End-Diensten im Namen des derzeit angemeldeten Benutzers dar. Die Anwendung kann dann den authorization_code im Hintergrund gegen ein access_token und ein refresh_token austauschen. Mit dem access_token kann die Anwendung sich in HTTP-Anforderungen bei einer Back-End-Web-API authentifizieren. Sie kann auch das refresh_token zum Abrufen eines neuen access_token verwenden, wenn ein älteres abläuft.

Daemons/serverseitige Anwendungen

Anwendungen, die lang andauernde Prozesse enthalten oder ohne Benutzereingriff arbeiten, benötigen auch die Möglichkeit, auf sichere Ressourcen wie Web-APIs zuzugreifen. Diese Anwendungen können mithilfe der Identität (anstelle der delegierten Benutzeridentität) und mithilfe des Client-Anmeldeinformationsflows von OAuth 2.0 die Authentifizierung durchführen und Token abrufen. Ein Client-Anmeldeinformationsflow ist nicht gleich einem „Im Auftrag von“-Flow, und im „Im Auftrag von“-Flow sollte nicht die Server-zu-Server-Authentifizierung verwendet werden.

Für Azure AD B2C befindet sich der Flow für OAuth 2.0-Clientanmeldeinformationen derzeit in der öffentlichen Vorschau. Sie können den Flow für Clientanmeldeinformationen allerdings mithilfe des Microsoft Entra ID- und 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 Artikel zur Microsoft Entra-Tokenreferenz.

Nicht unterstützte Anwendungstypen

Web-API-Ketten („Im Auftrag von“-Ablauf)

Viele Architekturen umfassen eine Web-API, von der eine andere Downstream-Web-API aufgerufen werden muss, wobei beide durch Azure AD B2C gesichert sind. Dieses Szenario kommt häufig bei nativen Clients mit Web-API-Back-End vor. Dabei wird ein Microsoft-Onlinedienst (z. B. die Microsoft Graph-API) aufgerufen.

Dieses Szenario der verketteten Web-API kann mithilfe der Berechtigung für Anmeldeinformationen über den OAuth 2.0-JWT-Bearer unterstützt werden, auch bekannt als „Im Auftrag von“-Ablauf. Der „Im Auftrag von“-Flow ist in Azure AD B2C derzeit jedoch noch nicht implementiert.

Nächste Schritte

Beschäftigen Sie sich ausführlicher mit den integrierten Richtlinien, die von Benutzerflows in Azure Active Directory B2C bereitgestellt werden.