Freigeben über

Codefluss für OAuth 2.0-Autorisierung in Azure Active Directory B2C

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.

Sie können die OAuth 2.0-Autorisierungscodegewährung in Apps verwenden, die auf einem Gerät installiert sind, um Zugriff auf geschützte Ressourcen wie Web-APIs zu erhalten. Mithilfe der Azure Active Directory B2C-Implementierung (Azure AD B2C) von OAuth 2.0 können Sie Ihren Single-Page-, Mobil- und Desktop-Apps Registrierungs-, Anmelde- und andere Identitätsverwaltungsaufgaben hinzufügen. In diesem Artikel beschreiben wir, wie Sie HTTP-Nachrichten senden und empfangen können, ohne Open-Source-Bibliotheken zu verwenden. Dieser Artikel ist sprachunabhängig. Es wird empfohlen, wenn möglich, die unterstützten Microsoft-Authentifizierungsbibliotheken (MSAL) zu verwenden. Werfen Sie einen Blick auf die Beispiel-Apps, die MSAL verwenden.

Der OAuth 2.0-Autorisierungscodefluss wird in Abschnitt 4.1 der OAuth 2.0-Spezifikationbeschrieben. Sie können es für die Authentifizierung und Autorisierung in den meisten Anwendungstypen verwenden, einschließlich Webanwendungen, Single-Page-Anwendungen und nativ installierten Anwendungen. Sie können den OAuth 2.0-Autorisierungscodeflow verwenden, um Zugriffstoken und Aktualisierungstoken für Ihre Anwendungen sicher abzurufen, die für den Zugriff auf Ressourcen verwendet werden können, die durch einen Autorisierungsserver gesichert sind. Das Aktualisierungstoken ermöglicht es dem Client, neue Zugriffstoken abzurufen (und zu aktualisieren), sobald das Zugriffstoken abläuft, in der Regel nach einer Stunde.

Dieser Artikel konzentriert sich auf den Codefluss für die OAuth 2.0-Autorisierung öffentlicher Clients . Ein öffentlicher Client ist eine Clientanwendung, der nicht vertraut werden kann, dass sie die Integrität eines geheimen Kennworts sicher aufrechterhält. Dazu gehören Single-Page-Anwendungen, mobile Apps, Desktop-Anwendungen und im Wesentlichen alle Anwendungen, die nicht auf einem Server ausgeführt werden.

Hinweis

Um einer Web-App mithilfe von Azure AD B2C eine Identitätsverwaltung hinzuzufügen, verwenden Sie OpenID Connect anstelle von OAuth 2.0.

Azure AD B2C erweitert die standardmäßigen OAuth 2.0-Flows um mehr als nur einfache Authentifizierung und Autorisierung. Es führt den Benutzerfluss ein. Mit Benutzerflows können Sie OAuth 2.0 verwenden, um Ihrer Anwendung Benutzeroberflächen hinzuzufügen, z. B. Registrierung, Anmeldung und Profilverwaltung. Zu den Identitätsanbietern, die das OAuth 2.0-Protokoll verwenden, gehören Amazon, Microsoft Entra ID, Facebook, GitHub, Google und LinkedIn.

So testen Sie die HTTP-Anforderungen in diesem Artikel:

  1. Ersetzen Sie {tenant} durch den Namen Ihres Azure AD B2C-Mandanten.
  2. Ersetzen Sie diese 00001111-aaaa-2222-bbbb-3333cccc4444 durch die App-ID einer Anwendung, die Sie zuvor in Ihrem Azure AD B2C-Mandanten registriert haben.
  3. Ersetzen Sie {policy} durch den Namen einer Richtlinie, die Sie in Ihrem Mandanten erstellt haben, z. B. b2c_1_sign_in.

Für Single-Page-Apps erforderliche Einrichtung eines Umleitungs-URI

Der Autorisierungscodeablauf für Single-Page-Anwendungen erfordert einige zusätzliche Setups. Befolgen Sie die Anweisungen zum Erstellen Ihrer Single-Page-Anwendung , um Ihren Umleitungs-URI ordnungsgemäß als für CORS aktiviert zu markieren. Um einen vorhandenen Umleitungs-URI zu aktualisieren, um CORS zu aktivieren, können Sie auf die Migrationsaufforderung im Abschnitt "Web" auf der Registerkarte "Authentifizierung" der App-Registrierung klicken. Alternativ können Sie den Manifest-Editor für App-Registrierungen öffnen und das type Feld für Ihren Umleitungs-URI spa im replyUrlsWithType Abschnitt auf festlegen.

Der spa Umleitungstyp ist abwärtskompatibel mit dem impliziten Ablauf. Apps, die derzeit den impliziten Flow zum Abrufen von Token verwenden, können ohne Probleme auf den Umleitungs-URI-Typ spa umgestellt werden und den impliziten Flow weiterhin verwenden.

1. Holen Sie sich einen Autorisierungscode

Der Autorisierungscodefluss beginnt damit, dass der Client den Benutzer auf den /authorize -Endpunkt leitet. Dies ist der interaktive Teil des Ablaufs, in dem der Benutzer eine Aktion ausführt. In dieser Anforderung gibt der Client im scope Parameter die Berechtigungen an, die er vom Benutzer abrufen muss. Die folgenden Beispiele (mit Zeilenumbrüchen zur besseren Lesbarkeit) zeigen, wie Sie einen Autorisierungscode abrufen. Wenn Sie diese GET-HTTP-Anforderung testen, verwenden Sie Ihren Browser.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Parameter Erforderlich? BESCHREIBUNG
{tenant} Erforderlich Name Ihres Azure AD B2C-Mandanten
{policy} Erforderlich Der auszuführende Benutzerflow. Geben Sie den Namen eines Benutzerflusses an, den Sie in Ihrem Azure AD B2C-Mandanten erstellt haben. Zum Beispiel: b2c_1_sign_in, b2c_1_sign_up, oder b2c_1_edit_profile.
Kunden-ID Erforderlich Die Anwendungs-ID, die Ihrer App im Azure-Portal zugewiesen wird.
Antworttyp Erforderlich Der Antworttyp, der code für den Autorisierungscodefluss enthalten muss. Sie können ein ID-Token erhalten, wenn Sie es in den Antworttyp einschließen, z. B. code+id_token. In diesem Fall muss der Bereich openid enthalten.
Weiterleitungs-URI Erforderlich Der Umleitungs-URI der App, in dem Authentifizierungsantworten gesendet und von der App empfangen werden. Er muss genau mit einem der Umleitungs-URIs übereinstimmen, die Sie im Portal registriert haben, mit dem Unterschied, dass er URL-codiert sein muss.
Umfang Erforderlich 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. Die Client-ID gibt an, dass die ausgestellten Token für die Verwendung durch den registrierten Azure AD B2C-Client bestimmt sind. 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.
Antwortmodus Empfohlen Die Methode, die zum Senden des resultierenden Autorisierungscodes zurück an Ihre App verwendet wird. Es kann sich um query, form_post oder fragment handeln.
Staat Empfohlen Ein Wert in der Anforderung, der eine Zeichenfolge mit beliebigem Inhalt Ihrer Wahl sein kann. Normalerweise wird ein zufällig generierter eindeutiger Wert verwendet, um eine websiteübergreifende Anforderungsfälschung zu verhindern. Der Status wird außerdem verwendet, um Informationen über den Status des Benutzers in der App zu codieren, bevor die Authentifizierungsanforderung aufgetreten ist. Dies kann z.B. die vom Benutzer besuchte Seite oder der ausgeführte Benutzerflow sein.
prompt Wahlfrei Die Art der Benutzerinteraktion, die erforderlich ist. Derzeit ist loginder einzige gültige Wert , der den Benutzer zwingt, seine Anmeldeinformationen für diese Anforderung einzugeben. Single Sign-On tritt nicht in Kraft.
Code-Herausforderung Empfohlen/erforderlich Wird verwendet, um die Erteilung von Autorisierungscodes über Proof Key for Code Exchange (PKCE) zu sichern. Erforderlich, wenn code_challenge_method enthalten ist. Sie müssen Ihrer Anwendung Logik hinzufügen, um code_verifier und code_challenge zu generieren. Das code_challenge ist ein Base64-URL-kodierter SHA256-Hash von code_verifier. Sie speichern die code_verifier in Ihrer Anwendung für die spätere Verwendung und senden sie code_challenge zusammen mit der Berechtigungsanforderung. Weitere Informationen finden Sie unter PKCE RFC. Dies wird jetzt für alle Anwendungstypen empfohlen – native Apps, SPAs und vertrauliche Clients wie Web-Apps.
code_challenge_method Empfohlen/erforderlich Die Methode wird zum Codieren von code_verifier für den code_challenge-Parameter verwendet. Dies SOLLTE sein S256, aber die Spezifikation erlaubt die Verwendung von plain , wenn der Client SHA256 aus irgendeinem Grund nicht unterstützen kann.

Wenn Sie code_challenge_method ausschließen, aber code_challenge noch einschließen, wird code_challenge als Klartext angenommen. Microsoft Identity Platform unterstützt sowohl plain als auch S256. Weitere Informationen finden Sie unter PKCE RFC. Dies ist für Single-Page-Apps erforderlich, die den Autorisierungscodeflow verwenden.
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. Beispielsweise URI für dynamischen Seiteninhalt oder OAuth2-Schlüssel-Wert-Parameter.

An diesem Punkt werden die Benutzenden aufgefordert, den Workflow des Benutzerflows abzuschließen. Dies kann bedeuten, dass der Benutzer seinen Benutzernamen und sein Kennwort eingibt, sich mit einer Identität in sozialen Netzwerken anmeldet, sich für das Verzeichnis anmeldet oder eine andere Anzahl von Schritten. Benutzeraktionen hängen davon ab, wie der Benutzerablauf definiert ist.

Nachdem der Benutzer den Benutzerflow abgeschlossen hat, gibt Microsoft Entra ID eine Antwort an Ihre App mit dem Wert zurück, den Sie für redirect_uriverwendet haben. Sie verwendet die im response_mode Parameter angegebene Methode. Die Antwort entspricht genau den einzelnen Benutzeraktionsszenarien, unabhängig vom ausgeführten Benutzerablauf.

Eine erfolgreiche Antwort, die response_mode=query verwendet, sieht wie folgt aus:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request
Parameter BESCHREIBUNG
Code Der von der App angeforderte Autorisierungscode. Die App kann den Autorisierungscode verwenden, um ein Zugriffstoken für eine Zielressource anzufordern. Autorisierungscodes sind nur von kurzer Dauer. In der Regel laufen sie nach etwa 10 Minuten ab.
Staat Die vollständige Beschreibung finden Sie in der Tabelle im vorherigen Abschnitt. Wenn ein Parameter state in der Anforderung enthalten ist, sollte der gleiche Wert in der Antwort angezeigt werden. Die App sollte überprüfen, ob die state Werte in der Anforderung und Antwort identisch sind.

Fehlerantworten können auch an den Umleitungs-URI gesendet werden, damit sie von der App entsprechend behandelt werden können:

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
Parameter BESCHREIBUNG
Fehler Eine Fehlercodezeichenfolge, die Sie zum Klassifizieren der auftretenden Fehlertypen verwenden können. Sie können auch die Zeichenfolge verwenden, um auf Fehler zu reagieren.
Fehlerbeschreibung Eine spezifische Fehlermeldung, mit der Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können.
Staat Die vollständige Beschreibung finden Sie in der vorstehenden Tabelle. Wenn ein Parameter state in der Anforderung enthalten ist, sollte der gleiche Wert in der Antwort angezeigt werden. Die App sollte überprüfen, ob die state Werte in der Anforderung und Antwort identisch sind.

2. Abrufen eines Zugriffstokens

Nachdem Sie nun einen Autorisierungscode abgerufen haben, können Sie das code für ein Token für die beabsichtigte Ressource 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 eigene Back-End-Web-API Ihrer App anfordern, indem Sie die Client-ID der App als angeforderten Bereich verwenden (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

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
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
Parameter Erforderlich? BESCHREIBUNG
{tenant} Erforderlich Name Ihres Azure AD B2C-Mandanten
{policy} Erforderlich Der Benutzerflow, der zum Abrufen des Autorisierungscodes verwendet wurde. Sie können in dieser Anforderung keinen anderen Benutzerflow verwenden.
Kunden-ID Erforderlich Die Anwendungs-ID, die Ihrer App im Azure-Portal zugewiesen wird.
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 in diesem Aufruf nicht verwendet. Wenn Sie einen geheimen Clientschlüssel verwenden, ändern Sie ihn regelmäßig.
Authentifizierungstyp (grant_type) Erforderlich Die Art des Zuschusses. Beim Autorisierungscodeflow muss der Gewährungstyp authorization_code sein.
Umfang Empfohlen Eine durch Leerzeichen getrennte Liste von Bereichen. Ein einzelner Bereichswert gibt für Azure AD B2C beide Berechtigungen an, die angefordert werden. Die Verwendung der Client-ID als Bereich gibt an, dass Ihre App ein Zugriffstoken benötigt, das für Ihren eigenen Dienst oder Ihre eigene Web-API verwendet werden kann, die durch dieselbe Client-ID dargestellt wird. Der offline_access Bereich gibt an, dass Ihre App ein Aktualisierungstoken für den langlebigen Zugriff auf Ressourcen benötigt. Sie können den openid Bereich auch verwenden, um ein ID-Token von Azure AD B2C anzufordern.
Code Erforderlich Der Autorisierungscode, den Sie vom /authorize Endpunkt abgerufen haben.
Weiterleitungs-URI Erforderlich Der Umleitungs-URI der Anwendung, in der Sie den Autorisierungscode erhalten haben.
Code-Überprüfer empfohlen Der code_verifier-Wert, der zum Abrufen des Autorisierungscodes verwendet wurde Erforderlich, wenn PKCE bei der Anforderung für die Gewährung des Autorisierungscodes verwendet wurde. Weitere Informationen finden Sie unter PKCE RFC.

Wenn Sie diese POST-HTTP-Anforderung testen, können Sie einen beliebigen HTTP-Client verwenden, z. B. Microsoft PowerShell.

Eine erfolgreiche Tokenantwort 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...",
}
Parameter BESCHREIBUNG
nicht vor Der Zeitpunkt in Epochenzeit, ab dem das Token gültig ist
Token-Typ Der Wert des Token-Typs. Der einzige Typ, der Microsoft Entra ID unterstützt, ist Bearer.
Zugriffstoken Das signierte JSON Web Token (JWT), das Sie angefordert haben.
Umfang Die Bereiche, für die das Token gültig ist. Sie können in den Bereichen auch Token für die spätere Verwendung zwischenspeichern.
expires_in Die Zeitspanne, die das Token gültig ist (in Sekunden).
Aktualisierungstoken Ein Aktualisierungstoken von OAuth 2.0. Die App kann dieses Token verwenden, um zusätzliche Token abzurufen, nachdem das aktuelle Token abgelaufen ist. Aktualisierungstoken sind langlebig. Sie können sie verwenden, um den Zugriff auf Ressourcen über einen längeren Zeitraum aufrechtzuerhalten. Weitere Informationen finden Sie in der Azure AD B2C-Tokenreferenz.

Fehlerantworten sehen wie folgt aus:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parameter BESCHREIBUNG
Fehler Eine Fehlercodezeichenfolge, die Sie zum Klassifizieren der auftretenden Fehlertypen verwenden können. Sie können auch die Zeichenfolge verwenden, um auf Fehler zu reagieren.
Fehlerbeschreibung Eine spezifische Fehlermeldung, mit der Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können.

3. Verwenden Sie den Token

Nachdem Sie nun 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 einfügen:

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

4. Aktualisiere das Token

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 sind identisch mit dem ursprünglich ausgestellten Zugriffstoken.

Um das Token zu aktualisieren, senden Sie eine weitere POST-Anforderung an den /token Endpunkt. Geben Sie dieses Mal das refresh_token anstelle des code.

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parameter Erforderlich? BESCHREIBUNG
{tenant} Erforderlich Name Ihres Azure AD B2C-Mandanten
{policy} Erforderlich Der Benutzerflow, der zum Abrufen des ursprünglichen Aktualisierungstokens verwendet wurde. Sie können in dieser Anforderung keinen anderen Benutzerflow verwenden.
Kunden-ID Erforderlich Die Anwendungs-ID, die Ihrer App im Azure-Portal zugewiesen wird.
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 in diesem Aufruf nicht verwendet. Wenn Sie einen geheimen Clientschlüssel verwenden, ändern Sie ihn in regelmäßigen Abständen.
Authentifizierungstyp (grant_type) Erforderlich Die Art des Zuschusses. Für diesen Teil des Autorisierungscodeflows muss der Berechtigungstyp lauten refresh_token.
Umfang Empfohlen Eine durch Leerzeichen getrennte Liste von Bereichen. Ein einzelner Bereichswert zeigt Microsoft Entra ID beide angeforderten Berechtigungen an. Die Verwendung der Client-ID als Bereich gibt an, dass Ihre App ein Zugriffstoken benötigt, das für Ihren eigenen Dienst oder Ihre eigene Web-API verwendet werden kann, die durch dieselbe Client-ID dargestellt wird. Der offline_access Bereich gibt an, dass Ihre App ein Aktualisierungstoken für den langlebigen Zugriff auf Ressourcen benötigt. Sie können den openid Bereich auch verwenden, um ein ID-Token von Azure AD B2C anzufordern.
Weiterleitungs-URI Wahlfrei Der Umleitungs-URI der Anwendung, in der Sie den Autorisierungscode erhalten haben.
Aktualisierungstoken Erforderlich Das ursprüngliche Aktualisierungstoken, das Sie im zweiten Abschnitt des Vorgangs erhalten haben

Eine erfolgreiche Tokenantwort 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...",
}
Parameter BESCHREIBUNG
nicht vor Der Zeitpunkt in Epochenzeit, ab dem das Token gültig ist
Token-Typ Der Wert des Token-Typs. Der einzige Typ, der Microsoft Entra ID unterstützt, ist Bearer.
Zugriffstoken Das signierte JWT, das Sie angefordert haben.
Umfang Die Bereiche, für die das Token gültig ist. Sie können in den Bereichen auch Tokens für die spätere Verwendung zwischenspeichern.
expires_in Die Zeitspanne, die das Token gültig ist (in Sekunden).
Aktualisierungstoken Ein Aktualisierungstoken von OAuth 2.0. Die App kann dieses Token verwenden, um zusätzliche Token abzurufen, nachdem das aktuelle Token abgelaufen ist. Aktualisierungstoken sind langlebig und können verwendet werden, um den Zugriff auf Ressourcen für längere Zeiträume beizubehalten. Weitere Informationen finden Sie in der Azure AD B2C-Tokenreferenz.

Fehlerantworten sehen wie folgt aus:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parameter BESCHREIBUNG
Fehler Eine Fehlercodezeichenfolge, die Sie zum Klassifizieren von auftretenden Fehlertypen verwenden können. Sie können auch die Zeichenfolge verwenden, um auf Fehler zu reagieren.
Fehlerbeschreibung Eine spezifische Fehlermeldung, mit der Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können.

Verwenden Sie Ihr eigenes Azure AD B2C-Verzeichnis

Um diese Anforderungen selbst auszuprobieren, führen Sie die folgenden Schritte aus. Ersetzen Sie die Beispielwerte, die wir in diesem Artikel verwendet haben, durch Ihre eigenen Werte.

  1. Erstellen Sie ein Azure AD B2C-Verzeichnis. Verwenden Sie den Namen Ihres Verzeichnisses in den Anfragen.
  2. Erstellen Sie eine Anwendung , um eine Anwendungs-ID und einen Umleitungs-URI abzurufen. Fügen Sie einen nativen Client in Ihre App ein.
  3. Erstellen Sie Ihre Benutzerabläufe, um Ihre Benutzerablaufnamen zu erhalten.