Web-Anmeldung mit OpenID Connect - Azure AD B2C

2025-05-08

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.

OpenID Connect ist ein Authentifizierungsprotokoll, das auf OAuth 2.0 aufbaut und zur sicheren Anmeldung von Benutzern bei Webanwendungen verwendet werden kann. Mithilfe der Azure Active Directory B2C-Implementierung (Azure AD B2C) von OpenID Connect können Sie die Registrierung, Anmeldung und andere Identitätsverwaltungsfunktionen in Ihren Webanwendungen an Microsoft Entra ID auslagern. Dieser Leitfaden zeigt Ihnen, wie Sie dies sprachunabhängig tun können. Es wird beschrieben, wie Sie HTTP-Nachrichten senden und empfangen können, ohne eine unserer Open-Source-Bibliotheken zu verwenden.

Hinweis

Die meisten Open-Source-Authentifizierungsbibliotheken rufen die JWTs für Ihre Anwendung ab und validieren sie. Es wird empfohlen, diese Optionen zu erkunden, anstatt Ihren eigenen Code zu implementieren. Weitere Informationen finden Sie unter Übersicht über die Microsoft Authentication Library (MSAL) und die Microsoft Identity Webauthentifizierungsbibliothek.

OpenID Connect erweitert das OAuth 2.0-Autorisierungsprotokoll um die Verwendung als Authentifizierungsprotokoll . Mit diesem Authentifizierungsprotokoll können Sie Single Sign-On durchführen. Es wird das Konzept eines ID-Tokens eingeführt, das es dem Client ermöglicht, die Identität des Benutzers zu überprüfen und grundlegende Profilinformationen über den Benutzer zu erhalten.

OpenID Connect ermöglicht es Anwendungen auch, Zugriffstoken sicher abzurufen. Sie können Zugriffstoken verwenden, um auf Ressourcen zuzugreifen, die vom Autorisierungsserver gesichert werden. Wir empfehlen OpenID Connect, wenn Sie eine Webanwendung erstellen, die Sie auf einem Server hosten und auf die Sie über einen Browser zugreifen. Weitere Informationen zu Token finden Sie in der Übersicht über Token in Azure Active Directory B2C

Azure AD B2C erweitert das standardmäßige OpenID Connect-Protokoll um mehr als nur einfache Authentifizierung und Autorisierung. Es wird der Parameter user flow eingeführt, mit dem Sie OpenID Connect verwenden können, um Ihrer Anwendung Benutzeroberflächen hinzuzufügen, z. B. Registrierung, Anmeldung und Profilverwaltung.

Senden 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 abhängig vom Benutzerablauf Aktionen aus.

In dieser Anforderung gibt der Client die Berechtigungen an, die er vom Benutzer scope im Parameter abrufen muss, und gibt den auszuführenden Benutzerflow an. Um die Funktionsweise der Anforderung zu spüren, fügen Sie die Anforderung in Ihren Browser ein, und führen Sie sie aus. Ersetzen:

{tenant} durch den Namen Ihres Mandanten
00001111-aaaa-2222-bbbb-3333cccc4444 mit der App-ID einer Anwendung, die Sie in Ihrem Mandanten registriert haben.
{application-id-uri}/{scope-name} durch den Anwendungs-ID-URI und den 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=00001111-aaaa-2222-bbbb-3333cccc4444
&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

Parameter	Erforderlich	BESCHREIBUNG
{tenant}	Ja	Name Ihres Azure AD B2C-Mandanten. Wenn Sie eine benutzerdefinierte Domain verwenden, ersetzen Sie `tenant.b2clogin.com` durch Ihre Domain, z.B. `fabrikam.com`.
{policy}	Ja	Der Benutzerflow oder die Richtlinie, der bzw. die von der App ausgeführt wird. Geben Sie den Namen eines Benutzerflows an, den Sie in Ihrem Azure AD B2C-Mandanten erstellen. Zum Beispiel: `b2c_1_sign_in`, `b2c_1_sign_up`, oder `b2c_1_edit_profile`.
Kunden-ID	Ja	Die Anwendungs-ID, die dem Azure-Portal Ihrer Anwendung zugewiesen wurde.
Nonce	Empfohlen	Ein Wert, der in der Anforderung enthalten ist (von der Anwendung generiert), der im resultierenden ID-Token als Anspruch enthalten ist. Die Anwendung kann diesen Wert dann überprüfen, um Token-Wiederholungsangriffe zu entschärfen. Der Wert ist in der Regel eine zufällige eindeutige Zeichenfolge, die verwendet werden kann, um den Ursprung der Anforderung zu identifizieren.
Antworttyp	Ja	Muss ein ID-Token für OpenID Connect enthalten. Wenn Ihre Webanwendung auch Token zum Aufrufen einer Web-API benötigt, können Sie `code+id_token` verwenden.
Umfang	Ja	Eine durch Leerzeichen getrennte Liste von Bereichen. Der `openid`-Bereich gibt eine Berechtigung für das Anmelden des Benutzers und das Abrufen von Daten über den Benutzer in Form von ID-Token an. Der `offline_access`-Bereich ist für Webanwendungen optional. Es gibt an, dass Ihre Anwendung ein Aktualisierungstoken für den erweiterten Zugriff auf Ressourcen benötigt. `https://{tenant-name}/{app-id-uri}/{scope}` gibt eine Berechtigung für geschützte Ressourcen (etwa eine Web-API) an. Weitere Informationen finden Sie unter Anfordern eines Zugriffstokens.
prompt	Nein	Die Art der Benutzerinteraktion, die Sie benötigen. Der einzige gültige Wert zu diesem Zeitpunkt ist `login`, der den Benutzer zwingt, seine Anmeldeinformationen für diese Anforderung einzugeben.
Weiterleitungs-URI	Ja	Der `redirect_uri` Parameter Ihrer Anwendung, an den der Server Authentifizierungsantworten an Ihre Anwendung sendet. Es muss genau einem der Parameter entsprechen, die Sie im Azure-Portal registriert haben, mit der Ausnahme, dass es URL-codiert sein muss.
Antwortmodus	Nein	Die Methode, die verwendet wird, um den resultierenden Autorisierungscode zurück an die Anwendung zu senden. Es kann entweder `query`, `form_post`oder `fragment`sein. Es wird empfohlen, den `form_post` Antwortmodus zu verwenden, um die beste Sicherheit zu gewährleisten.
Staat	Nein	Ein Wert, den Sie in die Anforderung einschließen können, die der Autorisierungsserver in der Tokenantwort zurückgibt. Dabei kann es sich um eine Zeichenfolge mit beliebigen Inhalten handeln. Ein zufällig generierter eindeutiger Wert wird normalerweise verwendet, um websiteübergreifende Anforderungsfälschungsangriffe zu verhindern. Der Status wird auch verwendet, um Informationen über den Status des Benutzers in der Anwendung zu codieren, bevor die Authentifizierungsanforderung aufgetreten ist, z. B. die Seite, auf der er sich befand. Wenn Sie nicht mehrere Umleitungs-URLs in Ihrem Azure-Portal registrieren möchten, können Sie den `state` Parameter verwenden, um Antworten in Ihrer Anwendung vom Azure AD B2C-Dienst aufgrund unterschiedlicher Anforderungen zu unterscheiden.
Login-Hinweis	Nein	Kann verwendet werden, um das Feld für den Anmeldenamen auf der Anmeldeseite vorab auszufüllen. Weitere Informationen finden Sie unter Vorausfüllen des Anmeldenamens.
domain_hint	Nein	Enthält einen Hinweis an Azure AD B2C über den Identitätsanbieter für soziale Netzwerke, der für die Anmeldung verwendet werden soll. Wenn ein gültiger Wert enthalten ist, wechselt der Benutzer direkt zur Anmeldeseite des Identitätsanbieters. Weitere Informationen finden Sie unter Umleitung der Anmeldung an einen Anbieter für soziale Netzwerke.
Benutzerdefinierte Parameter	Nein	Benutzerdefinierte Parameter, die mit benutzerdefinierten Richtlinien verwendet werden können. Beispiele: URI für dynamischen Seiteninhalt oder Konfliktlöser für Schlüsselwertansprüche

An dieser Stelle wird der Benutzer aufgefordert, den Workflow abzuschließen. Der Benutzer muss möglicherweise seinen Benutzernamen und sein Kennwort eingeben, sich mit einer Identität für soziale Netzwerke anmelden oder sich für das Verzeichnis registrieren. Es kann eine beliebige andere Anzahl von Schritten geben, je nachdem, wie der Benutzerflow definiert ist.

Nachdem Benutzende den Benutzerflow abgeschlossen hat, wird mithilfe der im Parameter redirect_uri angegebenen Methode eine Antwort über den angegebenen Parameter response_mode an Ihre Anwendung zurückgegeben. Die Antwort ist für jeden der vorhergehenden Fälle identisch, unabhängig vom Benutzerflow.

Eine erfolgreiche Antwort unter Verwendung von response_mode=fragment würde wie folgt aussehen:

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

Parameter	BESCHREIBUNG
id_token (Identitäts-Token)	Das ID-Token, das von der Anwendung angefordert wurde. Sie können mit dem ID-Token die Identität des Benutzers überprüfen und eine Sitzung mit dem Benutzer beginnen.
Code	Der Autorisierungscode, den die Anwendung angefordert hat, falls Sie `response_type=code+id_token` verwendet haben. Die Anwendung kann den Autorisierungscode verwenden, um ein Zugriffstoken für eine Zielressource anzufordern. Autorisierungscodes laufen in der Regel nach etwa 10 Minuten ab.
Staat	Wenn ein Parameter `state` in der Anforderung enthalten ist, sollte der gleiche Wert in der Antwort angezeigt werden. Die Anwendung sollte überprüfen, ob die `state` Werte in der Anforderung und Antwort identisch sind.

Fehlerantworten können auch an den redirect_uri Parameter gesendet werden, damit die Anwendung sie entsprechend 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

Parameter	BESCHREIBUNG
Fehler	Ein Code, der zum Klassifizieren der auftretenden Fehlertypen verwendet werden kann.
Fehlerbeschreibung	Eine bestimmte Fehlermeldung, die helfen kann, die Ursache eines Authentifizierungsfehlers zu identifizieren.
Staat	Wenn ein Parameter `state` in der Anforderung enthalten ist, sollte der gleiche Wert in der Antwort angezeigt werden. Die Anwendung sollte überprüfen, ob die `state` Werte in der Anforderung und Antwort identisch sind.

Überprüfen des ID-Tokens

Der bloße Erhalt eines ID-Tokens reicht nicht aus, um den Benutzer zu authentifizieren. Überprüfen 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 (JWTs) und Kryptografie für öffentliche Schlüssel, um Token zu signieren und zu überprüfen, ob sie gültig sind.

Hinweis

Die meisten Open-Source-Authentifizierungsbibliotheken validieren die JWTs für Ihre Anwendung. Es wird empfohlen, diese Optionen zu erkunden, anstatt eine eigene Validierungslogik zu implementieren. Weitere Informationen finden Sie unter Übersicht über die Microsoft Authentication Library (MSAL) und die Microsoft Identity Webauthentifizierungsbibliothek.

Azure AD B2C verfügt über einen OpenID Connect-Metadatenendpunkt, mit dem eine Anwendung zur Laufzeit Informationen über Azure AD B2C abrufen kann. Diese Informationen umfassen Endpunkte, Tokeninhalte und Tokensignaturschlüssel. Es gibt ein JSON-Metadatendokument für jeden Benutzerflow in Ihrem B2C-Mandanten. 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 denselben Benutzerflow wie folgt lauten würde:

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

Um zu bestimmen, welcher Benutzerflow zum Signieren eines ID-Tokens verwendet wurde, haben Sie zwei Möglichkeiten. 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 im Wert des state Parameters zu codieren, wenn Sie die Anforderung ausgeben, und ihn dann zu decodieren, um zu bestimmen, welcher Benutzerflow verwendet wurde. Beide Methoden sind gültig.

Nachdem Sie das Metadatendokument vom OpenID Connect-Metadatenendpunkt abgerufen haben, können Sie die öffentlichen RSA 256-Schlüssel verwenden, um die Signatur des ID-Tokens zu validieren. An diesem Endpunkt sind möglicherweise mehrere Schlüssel aufgeführt, die jeweils durch einen kid Anspruch identifiziert werden. Der Header des ID-Tokens enthält auch einen kid Anspruch, der angibt, welcher dieser Schlüssel zum Signieren des ID-Tokens verwendet wurde.

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

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

Überprüfen Sie den nonce-Anspruch, um Tokenwiederholungsangriffe zu verhindern. Der Wert sollte das sein, was Sie in der Anmeldeanforderung angegeben haben.
Überprüfen Sie den aud Anspruch, um sicherzustellen, dass das ID-Token für Ihre Anwendung ausgestellt wurde. Der Wert sollte die Anwendungs-ID Ihrer Anwendung sein.
Überprüfen Sie die Ansprüche iat und exp, um sicherzustellen, dass das ID-Token nicht abgelaufen ist.

Es gibt auch einige weitere Validierungen, die Sie durchführen sollten. Die Validierungen sind in der OpenID Connect Core Spec ausführlich beschrieben. Je nach Szenario können Sie auch weitere Ansprüche überprüfen. Einige allgemeine Überprüfungen umfassen:

Stellen Sie sicher, dass sich der Benutzer/die Organisation für die Anwendung angemeldet hat.
Stellen Sie sicher, dass der Benutzer über die richtigen Berechtigungen verfügt.
Stellen Sie sicher, dass eine bestimmte Authentifizierungsstärke aufgetreten ist, z. B. Microsoft Entra Multifaktor-Authentifizierung.

Nachdem das ID-Token überprüft wurde, können Sie eine Sitzung mit dem Benutzer beginnen. Sie können die Ansprüche im ID-Token verwenden, um Informationen über den Benutzer in Ihrer Anwendung abzurufen. Zu den Verwendungszwecken für diese Informationen gehören Anzeige, Datensätze und Autorisierung.

Abrufen von Token

Wenn Sie möchten, dass Ihre Webanwendung nur Benutzerflows ausführt, können Sie die nächsten Abschnitte überspringen. Diese Abschnitte gelten nur für Webanwendungen, die authentifizierte Aufrufe an eine Web-API ausführen müssen, die durch Azure AD B2C selbst geschützt ist.

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

Sie können auch ein Zugriffstoken für die Back-End-Web-API Ihrer App anfordern. In diesem Fall verwenden Sie die Client-ID der App als angeforderten Bereich, was zu einem Zugriffstoken mit dieser Client-ID als "Zielgruppe" führt:

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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parameter	Erforderlich	BESCHREIBUNG
{tenant}	Ja	Name Ihres Azure AD B2C-Mandanten
{policy}	Ja	Der Benutzerflow, der zum Abrufen des Autorisierungscodes verwendet wurde. Sie können in dieser Anforderung keinen anderen Benutzerflow verwenden. Fügen Sie diesen Parameter der Abfragezeichenfolge und nicht dem POST-Text hinzu.
Kunden-ID	Ja	Die Anwendungs-ID, die dem Azure-Portal Ihrer Anwendung zugewiesen wurde.
client_secret (Kunden-Geheimnis)	Ja, in Web-Apps	Der geheime Anwendungsschlüssel, der im Azure-Portal generiert wurde. Geheime Clientschlüssel werden in diesem Ablauf für Web-App-Szenarien verwendet, in denen der Client einen geheimen Clientschlüssel sicher speichern kann. Bei Szenarien mit nativer App (öffentlicher Client) können geheime Clientschlüssel nicht sicher gespeichert und daher nicht für diesen Ablauf verwendet werden. Wenn Sie einen geheimen Clientschlüssel verwenden, ändern Sie ihn regelmäßig.
Code	Ja	Der Autorisierungscode, den Sie zu Beginn des Benutzerflows abgerufen haben.
Authentifizierungstyp (grant_type)	Ja	Der Berechtigungstyp, der für den Autorisierungscodefluss `authorization_code` lauten muss.
Weiterleitungs-URI	Nein	Der `redirect_uri` Parameter der Anwendung, in der Sie den Autorisierungscode erhalten haben.
Umfang	Nein	Eine durch Leerzeichen getrennte Liste von Bereichen. Der `openid` Bereich gibt eine Berechtigung zum Anmelden des Benutzers und zum Abrufen von Daten über den Benutzer in Form von id_token Parametern an. Sie kann verwendet werden, um Token für die Back-End-Web-API Ihrer Anwendung abzurufen, die durch dieselbe Anwendungs-ID wie der Client dargestellt wird. Der `offline_access` Bereich gibt an, dass Ihre Anwendung ein Aktualisierungstoken für den erweiterten Zugriff auf Ressourcen benötigt.

Eine erfolgreiche Token-Antwort sieht wie folgt aus:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parameter	BESCHREIBUNG
nicht vor	Der Epochenzeitpunkt, zu dem das Token gültig wird.
Token-Typ	Der Wert des Tokentyps. `Bearer` ist der einzige Typ, der unterstützt wird.
Zugriffstoken	Das signierte JWT, das Sie angefordert haben.
Umfang	Die gültigen Geltungsbereiche des Tokens.
expires_in	Die Dauer der Gültigkeit des Zugriffstokens (in Sekunden).
läuft_ab_am	Der Zeitstempel, zu dem das Zugriffstoken ungültig wird.
Aktualisierungstoken	Ein Aktualisierungstoken von OAuth 2.0. Die Anwendung kann dieses Token verwenden, um weitere Token abzurufen, nachdem das aktuelle Token abgelaufen ist. Aktualisierungstoken können verwendet werden, um den Zugriff auf Ressourcen für längere Zeiträume beizubehalten. Der Bereich `offline_access` muss sowohl in der Autorisierungs- als auch in der Tokenanforderung verwendet worden sein, um ein Aktualisierungstoken zu erhalten.

Fehlerantworten sehen wie folgt aus:

{
    "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"
}

Parameter	BESCHREIBUNG
Fehler	Ein Code, der zum Klassifizieren von auftretenden Fehlertypen verwendet werden kann.
Fehlerbeschreibung	Eine Meldung, die helfen kann, die Ursache eines Authentifizierungsfehlers zu identifizieren.

Verwenden Sie den Token

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

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

Token aktualisieren

Zugriffstoken und ID-Token sind nur von kurzer Dauer. Nach 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.

Aktualisieren Sie ein Token, indem Sie eine weitere POST Anforderung an den /token Endpunkt senden. Geben Sie dieses Mal den refresh_token Parameter anstelle des code Parameters 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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parameter	Erforderlich	BESCHREIBUNG
{tenant}	Ja	Name Ihres Azure AD B2C-Mandanten
{policy}	Ja	Der Benutzerflow, der zum Abrufen des ursprünglichen Aktualisierungstokens verwendet wurde. Sie können in dieser Anforderung keinen anderen Benutzerflow verwenden. Fügen Sie diesen Parameter der Abfragezeichenfolge und nicht dem POST-Text hinzu.
Kunden-ID	Ja	Die Anwendungs-ID, die dem Azure-Portal Ihrer Anwendung zugewiesen wurde.
client_secret (Kunden-Geheimnis)	Ja, in Web-Apps	Der geheime Anwendungsschlüssel, der im Azure-Portal generiert wurde. Geheime Clientschlüssel werden in diesem Ablauf für Web-App-Szenarien verwendet, in denen der Client einen geheimen Clientschlüssel sicher speichern kann. Bei Szenarien mit nativer App (öffentlicher Client) können geheime Clientschlüssel nicht sicher gespeichert werden und werden daher bei diesem Aufruf nicht verwendet. Wenn Sie einen geheimen Clientschlüssel verwenden, ändern Sie ihn in regelmäßigen Abständen.
Authentifizierungstyp (grant_type)	Ja	Der Berechtigungstyp, der für diesen Teil des Autorisierungscodeflows `refresh_token` lauten muss.
Aktualisierungstoken	Ja	Das ursprüngliche Aktualisierungstoken, das im zweiten Teil des Flows erhalten wurde. Der `offline_access` Bereich muss sowohl in den Autorisierungs- als auch in den Tokenanforderungen verwendet werden, um ein Aktualisierungstoken zu erhalten.
Weiterleitungs-URI	Nein	Der `redirect_uri` Parameter der Anwendung, in der Sie den Autorisierungscode erhalten haben.
Umfang	Nein	Eine durch Leerzeichen getrennte Liste von Bereichen. Der `openid`-Bereich gibt eine Berechtigung für das Anmelden des Benutzers und das Abrufen von Daten über den Benutzer in Form von ID-Token an. Sie kann verwendet werden, um Token an die Back-End-Web-API Ihrer Anwendung zu senden, die durch dieselbe Anwendungs-ID wie der Client dargestellt wird. Der `offline_access` Bereich gibt an, dass Ihre Anwendung ein Aktualisierungstoken für den erweiterten Zugriff auf Ressourcen benötigt.

Eine erfolgreiche Token-Antwort sieht wie folgt aus:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

Parameter	BESCHREIBUNG
nicht vor	Der Epochenzeitpunkt, zu dem das Token gültig wird.
Token-Typ	Der Wert des Tokentyps. `Bearer` ist der einzige Typ, der unterstützt wird.
Zugriffstoken	Das signierte JWT, das angefordert wurde.
Umfang	Die gültigen Geltungsbereiche des Tokens.
expires_in	Die Dauer der Gültigkeit des Zugriffstokens (in Sekunden).
Aktualisierungstoken	Ein Aktualisierungstoken von OAuth 2.0. Die Anwendung kann dieses Token verwenden, um nach Ablauf des aktuellen Tokens weitere Token abzurufen. Aktualisierungstoken können verwendet werden, um den Zugriff auf Ressourcen für längere Zeiträume beizubehalten.
refresh_token_expires_in	Die Zeitspanne, die das Aktualisierungstoken gültig ist (in Sekunden).

Fehlerantworten sehen wie folgt aus:

{
    "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",
}

Parameter	BESCHREIBUNG
Fehler	Ein Code, der zum Klassifizieren von auftretenden Fehlertypen verwendet werden kann.
Fehlerbeschreibung	Eine Meldung, die helfen kann, die Ursache eines Authentifizierungsfehlers zu identifizieren.

Senden einer Abmeldeanforderung

Wenn Sie den Benutzer von der Anwendung abmelden möchten, reicht es nicht aus, die Cookies der Anwendung zu löschen oder die Sitzung mit dem Benutzer anderweitig zu beenden. Leiten Sie den Benutzer zu Azure AD B2C um, um sich abzumelden. Wenn Sie dies nicht tun, kann sich der Benutzer möglicherweise erneut bei Ihrer Anwendung authentifizieren, ohne seine Anmeldeinformationen erneut eingeben zu müssen. Weitere Informationen finden Sie unter Azure AD B2C-Sitzungsverhalten.

Um den Benutzer abzumelden, leiten Sie ihn an die im zuvor beschriebenen OpenID Connect-Metadatendokument aufgeführte URL end_session_endpoint weiter.

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

Parameter	Erforderlich	BESCHREIBUNG
{tenant}	Ja	Name Ihres Azure AD B2C-Mandanten. Wenn Sie eine benutzerdefinierte Domain verwenden, ersetzen Sie `tenant.b2clogin.com` durch Ihre Domain, z.B. `fabrikam.com`.
{policy}	Ja	Der Benutzerflow, den Sie in der Autorisierungsanforderung angeben. Wenn sich der Benutzer beispielsweise mit dem Benutzerflow `b2c_1_sign_in` angemeldet hat, geben Sie `b2c_1_sign_in` in der Abmeldeanforderung an.
id_token_hint	Nein	Ein zuvor ausgestelltes ID-Token, das als Hinweis auf die aktuelle authentifizierte Sitzung des Endbenutzers mit dem Client an den Abmeldeendpunkt übergeben werden soll. `id_token_hint` stellt sicher, dass `post_logout_redirect_uri` eine registrierte Antwort-URL in Ihren Azure AD B2C-Anwendungseinstellungen darstellt. Weitere Informationen finden Sie unter Absichern Ihrer Abmeldeumleitung.
Kunden-ID	Nein*	Die Anwendungs-ID, die dem Azure-Portal Ihrer Anwendung zugewiesen wurde. * `No`
post_logout_redirect_uri	Nein	Die URL, zu der der Benutzer nach erfolgreicher Abmeldung umgeleitet werden soll. Wenn sie nicht enthalten ist, zeigt Azure AD B2C dem Benutzer eine generische Nachricht an. Wenn Sie nicht eine `id_token_hint`angeben, sollten Sie diese URL nicht als Antwort-URL in Ihren Azure AD B2C-Anwendungseinstellungen registrieren.
Staat	Nein	Wenn Sie einen `state` Parameter in die Autorisierungsanforderung aufnehmen, gibt der Autorisierungsserver denselben Wert in der Antwort auf `post_logout_redirect_uri`. Die Anwendung sollte überprüfen, ob der `state` Wert in der Anforderung und der Antwort identisch ist.

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

Schützen der Umleitung beim Abmelden

Nach der Abmeldung wird der Benutzer zu dem URI umgeleitet, den Sie im post_logout_redirect_uri Parameter angeben, unabhängig von den Antwort-URLs, die Sie für die Anwendung angegeben haben. Wenn jedoch ein gültiges id_token_hint Kennwort ü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 mit einem der konfigurierten Umleitungs-URIs der Anwendung übereinstimmt, bevor die Umleitung ausgeführt wird. Wenn für die Anwendung keine übereinstimmende 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.

Erfahren Sie mehr über Azure AD B2C-Sitzungen.

Freigeben über

Webanmeldung mit OpenID Connect in Azure Active Directory B2C