Webanmeldung mit OpenID Connect in Azure Active Directory B2C

OpenID Connect ist ein Authentifizierungsprotokoll auf Grundlage von OAuth 2.0, mit dem Benutzer sicher bei Webanwendungen angemeldet werden können. Mithilfe der Azure AD B2C-Implementierung von OpenID Connect können Sie Registrierungs-, Anmeldungs- und sonstige Identitätsverwaltungsvorgänge Ihrer Webanwendungen nach Microsoft Entra ID auslagern. In diesem Leitfaden wird dies sprachunabhängig erläutert. Er beschreibt das Senden und Empfangen von HTTP-Nachrichten ohne Verwendung unserer Open Source-Bibliotheken.

OpenID Connect erweitert das OAuth 2.0-Protokoll für die Autorisierung, damit es als Protokoll für die Authentifizierung verwendet werden kann. Authentifizierungsprotokoll ermöglicht Ihnen das Ausführen von SSO (Einmaliges Anmelden). Dabei wird das Konzept eines ID-Tokens eingeführt, mit dem der Client die Identität des Benutzers überprüfen und grundlegende Profilinformationen über den Benutzer erhalten kann.

OpenID Connect ermöglicht es Anwendungen auch, Zugriffstoken sicher abzurufen. Mit Zugriffstoken können Sie auf die Ressourcen zugreifen, die der Autorisierungsserver sichert. OpenID Connect wird empfohlen, wenn Sie eine Webanwendung erstellen, die Sie auf einem Server hosten und auf die über einen Browser zugegriffen wird. Weitere Informationen zu Token finden Sie in der Übersicht über Token in Azure Active Directory B2C.

Azure AD B2C erweitert das OpenID Connect-Standardprotokoll, sodass mehr als nur eine einfache Authentifizierung und Autorisierung erfolgt. Der Benutzerflowparameter wird eingeführt, mit dem Sie OpenID Connect zum Hinzufügen von Benutzeroberflächen (z. B. für die Registrierung, Anmeldung und Profilverwaltung) zu Ihrer Anwendung verwenden können.

Übermitteln von Authentifizierungsanforderungen

Wenn Ihre Webanwendung den Benutzer authentifizieren und einen Benutzerflow ausführen muss, kann sie den Benutzer an den /authorize-Endpunkt weiterleiten. Der Benutzer führt Aktionen in Abhängigkeit vom Benutzerflow durch.

In dieser Anforderung gibt der Client die Berechtigungen, die er vom Benutzer benötigt, im Parameter scope an, und er gibt den auszuführenden Benutzerflow an. Fügen Sie die Anforderung in Ihren Browser ein, und führen Sie sie aus, um ein Gefühl für die Funktionsweise der Anforderung zu bekommen. Ersetzen Sie:

• {tenant} durch den Namen Ihres Mandanten.
• 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 mit der App-ID einer Anwendung, die Sie in Ihrem Mandanten registriert haben.
• {application-id-uri}/{scope-name} mit dem Anwendungs-ID-URI und dem Bereich einer Anwendung, die Sie in Ihrem Mandanten registriert haben.
• {policy} durch den Richtliniennamen in Ihrem Mandanten, z. B. b2c_1_sign_in.

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

An diesem Punkt wird der Benutzer aufgefordert, den Workflow abzuschließen. Der Benutzer muss möglicherweise seinen Benutzernamen und sein Kennwort eingeben, sich mit einer Social-Media-Identität anmelden oder sich für das Verzeichnis registrieren. Je nach Definition des Benutzerflows ist eine andere Zahl von Schritten auszuführen.

Nachdem der bzw. die Benutzer*in den Benutzerflow abgeschlossen hat, wird mithilfe der im Parameter response_mode angegebenen Methode eine Antwort über den angegebenen Parameter redirect_uri an Ihre Anwendung zurückgegeben. Die Antwort ist in jedem der vorangegangenen Fälle immer gleich, unabhängig vom jeweiligen Benutzerflow.

Eine erfolgreiche Antwort mit response_mode=fragment sieht wie folgt aus:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response

Fehlerantworten können auch an den redirect_uri-Parameter gesendet werden, damit die Anwendung diese angemessen behandeln kann:

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response

Überprüfen des ID-Tokens

Das Empfangen eines ID-Tokens reicht nicht aus, um den bzw. die Benutzer*in zu authentifizieren. Validieren Sie die Signatur des ID-Tokens, und überprüfen Sie die Ansprüche im Token gemäß den Anforderungen Ihrer Anwendung. Azure AD B2C verwendet JSON-Webtoken (JWT) und die Kryptografie mit öffentlichem Schlüssel, um Token zu signieren und deren Gültigkeit zu überprüfen.

Azure AD B2C verfügt über einen OpenID Connect-Metadatenendpunkt, mit dem die Anwendung zur Laufzeit Informationen über Azure AD B2C abrufen kann. Diese Informationen umfassen Endpunkte, Tokeninhalte und Token-Signaturschlüssel. Für jeden Benutzerflow ist in Ihrem B2C-Mandanten ein JSON-Metadatendokument vorhanden. Das Metadatendokument für den Benutzerflow b2c_1_sign_in in fabrikamb2c.onmicrosoft.com befindet sich beispielsweise unter:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Eine der Eigenschaften dieses Konfigurationsdokuments ist jwks_uri, deren Wert für den gleichen Benutzerflow wie folgt lautet:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Es gibt zwei Möglichkeiten zum Ermitteln, welcher Benutzerflow zum Signieren eines ID-Tokens verwendet wurde. Zuerst ist der Name des Benutzerflows im Anspruch acr im ID-Token enthalten. Weitere Informationen finden Sie unter Anspruch, der den Benutzerflow darstellt. Die andere Möglichkeit besteht darin, den Benutzerflow beim Übermitteln der Anforderung im Wert des Parameters state zu verschlüsseln und später zu entschlüsseln, um zu bestimmen, welcher Benutzerflow verwendet wurde. Beide Methoden sind gültig.

Nachdem Sie das Metadatendokument aus dem OpenID Connect-Metadatenendpunkt erhalten haben, können Sie die öffentlichen RSA-256-Schlüssel zum Überprüfen der Signatur des ID-Tokens verwenden. Es gibt möglicherweise mehrere Schlüssel an diesem Endpunkt. Sie werden jeweils durch einen kid-Anspruch identifiziert. Der Header des ID-Tokens enthält außerdem einen kid-Anspruch, der anzeigt, welcher Schlüssel zum Signieren des ID-Tokens verwendet wurde.

Sie müssen den öffentlichen Schlüssel mithilfe von Exponent (e) und Modulus (n) generieren, um die Token von Azure AD B2C zu überprüfen. Dazu müssen Sie lernen, wie Sie den öffentlichen Schlüssel in einer Programmiersprache Ihrer Wahl generieren. Die offizielle Dokumentation zur Generierung öffentlicher Schlüssel mit dem RSA-Protokoll finden Sie hier: https://tools.ietf.org/html/rfc3447#section-3.1

Nachdem Sie die Signatur des ID-Tokens validiert haben, gibt es verschiedene Ansprüche, die Sie überprüfen müssen. Beispiel:

• Überprüfen Sie den nonce-Anspruch, um Tokenwiederholungsangriffe zu verhindern. Dessen Wert sollte dem in der Anmeldeanforderung angegebenen Wert entsprechen.
• Überprüfen Sie den aud-Anspruch, um sicherzustellen, dass das ID-Token für Ihre Anwendung ausgegeben wurde. Der Wert sollte der Anwendungs-ID der Anwendung entsprechen.
• Überprüfen Sie die Ansprüche iat und exp, um sicherzustellen, dass das ID-Token nicht abgelaufen ist.

Es gibt auch einige weitere Überprüfungen, die Sie durchführen sollten. Diese Überprüfungen werden ausführlich in der OpenID Connect Core Spec (Core-Spezifikation des OpenID Connect) beschrieben. Sie können je nach Szenario auch weitere Ansprüche überprüfen. Einige allgemeinen Überprüfungen umfassen:

• Sicherstellen, dass sich der bzw. die Benutzer*in/die Organisation für die Anwendung registriert hat.
• Sicherstellen, dass der bzw. die Benutzer*in über eine ordnungsgemäße Autorisierung und die richtigen Berechtigungen verfügt.
• Sicherstellen, dass eine bestimmte Authentifizierungsmethode verwendet wird, z. B. die Multi-Faktor-Authentifizierung von Microsoft Entra.

Nachdem das ID-Token validiert wurde, können Sie eine Sitzung mit dem Benutzer beginnen. Verwenden Sie die Ansprüche im ID-Token, um Informationen über den Benutzer in Ihrer Anwendung zu erhalten. Die Verwendung dieser Information umfasst die Anzeige, Datensätze und Autorisierung.

Abrufen von Token

Wenn Ihre Webanwendung nur Benutzerflows ausführen soll, können Sie die nächsten Abschnitte überspringen. Diese Abschnitte gelten nur für Webanwendungen, die authentifizierte Aufrufe an eine Web-API durchführen müssen, die von Azure AD B2C geschützt wird.

Sie können den erhaltenen Autorisierungscode (mit response_type=code+id_token) für ein Token für die gewünschte Ressource einlösen, indem Sie eine POST-Anforderung an den /token-Endpunkt senden. In Azure AD B2C können Sie Zugriffstoken für andere APIs wie gewohnt anfordern, indem Sie ihre Bereiche in der Anforderung angeben.

Sie haben auch die Möglichkeit, ein Zugriffstoken für die Back-End-Web-API Ihrer App anzufordern. In diesem Fall verwenden Sie die Client-ID der App als angeforderten Bereich. Dies führt dazu, dass ein Zugriffstoken mit dieser Client-ID als „Zielgruppe“ erstellt wird:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Eine erfolgreiche Token-Antwort sieht wie folgt aus:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Fehlerantworten sehen aus wie folgt:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}

Verwenden des Tokens

Nachdem Sie erfolgreich ein Zugriffstoken erhalten haben, können Sie das Token für Anforderungen an die Back-End-Web-APIs verwenden, indem Sie es in den Authorization-Header einschließen:

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Aktualisieren des Tokens

Zugriffs- und ID-Tokens sind kurzlebig. Nach ihrem Ablauf müssen Sie sie aktualisieren, um weiterhin auf Ressourcen zugreifen zu können. Wenn Sie das Zugriffstoken aktualisieren, gibt Azure AD B2C ein neues Token zurück. Das aktualisierte Zugriffstoken verfügt über die Anspruchswerte nbf (nicht vor), iat (ausgestellt um) und exp (Ablauf). Alle anderen Anspruchswerte ähneln denen im vorherigen Zugriffstoken.

Zum Aktualisieren eines Tokens übermitteln Sie eine weitere POST-Anforderung an den /token-Endpunkt. Geben Sie diesmal den refresh_token-Parameter anstelle von code an:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Eine erfolgreiche Token-Antwort sieht wie folgt aus:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

Fehlerantworten sehen aus wie folgt:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}

Senden einer Abmeldeanforderung

Wenn Sie den Benutzer bei der Anwendung abmelden möchten, reicht es nicht aus, die Cookies der Anwendung zu löschen oder die Sitzung mit dem Benutzer auf andere Weise zu beenden. Leiten Sie den Benutzer für die Abmeldung zu Azure AD B2C um. Wenn Sie dies versäumen, kann sich der Benutzer möglicherweise erneut bei Ihrer Anwendung authentifizieren, ohne die Anmeldeinformationen erneut eingeben zu müssen. Weitere Informationen finden Sie unter Azure AD B2C-Sitzungsverhalten.

Um den Benutzer abzumelden, leiten Sie ihn an den end_session_endpoint um, der im oben beschriebenen OpenID Connect-Metadatendokument aufgeführt wird:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F

Bei einer Abmeldeanforderung erklärt Azure AD B2C die cookiebasierte Azure AD B2C-Sitzung für ungültig und versucht, sich von Verbundidentitätsanbietern abzumelden. Weitere Informationen finden Sie unter Einmaliges Abmelden.

Sichern der Umleitung beim Abmelden

Nach der Abmeldung wird der bzw. die Benutzer*in zu der im Parameter post_logout_redirect_uri angegebenen URI umgeleitet, unabhängig von den Antwort-URLs, die Sie für die Anwendung angeben. Wenn jedoch ein gültiger id_token_hint-Wert übergeben wird und die Option ID-Token in Abmeldeanforderungen erforderlich aktiviert ist, überprüft Azure AD B2C, ob der Wert von post_logout_redirect_uri einem der für die Anwendung konfigurierten Umleitungs-URIs entspricht, bevor die Umleitung ausgeführt wird. Wenn für die Anwendung keine entsprechende Antwort-URL konfiguriert wurde, wird eine Fehlermeldung angezeigt und der Benutzer wird nicht umgeleitet.

Informationen zum Festlegen des erforderlichen ID-Tokens in Abmeldeanforderungen finden Sie unter Konfigurieren des Sitzungsverhaltens in Azure Active Directory B2C.

Nächste Schritte

• Weitere Informationen zur Azure AD B2C-Sitzung.