Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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
undexp
, 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.
Verwandte Inhalte
- Erfahren Sie mehr über Azure AD B2C-Sitzungen.