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.
Hinweis
Die meisten Open-Source-Authentifizierungsbibliotheken erwerben und validieren die JWT-Token für Ihre Anwendung. Wir empfehlen die Verwendung einer dieser Optionen, anstatt Ihren eigenen Code zu implementieren. Weitere Informationen finden Sie in der Übersicht über die Microsoft-Authentifizierungsbibliothek (MSAL) und unter Microsoft Identity Web-Authentifizierungsbibliothek.
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-b8bbc0b29dc6mit 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
| Parameter | Erforderlich | BESCHREIBUNG |
|---|---|---|
| {tenant} | Ja | Name Ihres Azure AD B2C-Mandanten Wenn Sie eine benutzerdefinierte Domäne verwenden, ersetzen Sie tenant.b2clogin.com durch Ihre Domäne, 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. Beispiel: b2c_1_sign_in, b2c_1_sign_up oder b2c_1_edit_profile. |
| client_id | Ja | Die Anwendungs-ID, die das Azure-Portal Ihrer Anwendung zugewiesen hat. |
| nonce | Ja | Ein Wert in der Anforderung, der von der Anwendung generiert wird und im resultierenden ID-Token als Anspruch enthalten ist. Die Anwendung kann diesen Wert dann überprüfen, um die Gefahr von Token-Replay-Angriffen zu vermindern. Der Wert ist in der Regel eine zufällige, eindeutige Zeichenfolge, die verwendet werden kann, um den Ursprung der Anforderung zu identifizieren. |
| response_type | Ja | Muss ein ID-Token für OpenID Connect enthalten. Wenn Ihre Webanwendung auch Token für den Aufruf einer Web-API benötigt, können Sie code+id_token verwenden. |
| scope | 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. Er 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 im Artikel zum Anfordern eines Zugriffstokens in Azure Active Directory B2C unter Bereiche. |
| prompt | Nein | Der Typ der erforderlichen Benutzerinteraktion. Zu diesem Zeitpunkt ist der einzige gültige Wert login, der den Benutzer zur Eingabe von Anmeldeinformationen für diese Anforderung zwingt. |
| redirect_uri | Ja | Der Parameter redirect_uri der Anwendung, in dem der Server Authentifizierungsantworten an Ihre Anwendung sendet. Er muss genau mit einem der redirect_uri-Parameter übereinstimmen, die Sie im Azure-Portal registriert haben, mit dem Unterschied, dass er URL-codiert sein muss. |
| response_mode | Nein | Die Methode, die zum Senden des resultierenden Autorisierungscodes zurück an Ihre Anwendung verwendet wird. Es kann sich um query, form_post, oder fragment handeln. Es wird empfohlen, den Antwortmodus form_post für die optimale Sicherheit zu verwenden. |
| state | Nein | Ein Wert, den Sie in die Anforderung einschließen können und den der Autorisierungsserver in der Tokenantwort zurückgibt. Es kann sich um eine Zeichenfolge mit jedem beliebigen Inhalt handeln. Ein zufällig generierter eindeutiger Wert wird normalerweise verwendet, um websiteübergreifende Anforderungsfälschungsangriffe zu verhindern. Der Status wird auch zum Codieren von Informationen über den Status des Benutzers in der Anwendung vor der Authentifizierungsanforderung verwendet, z.B. für Informationen zu der Seite, die der Benutzer besucht hat. Wenn Sie nicht mehrere Umleitungs-URLs in Ihrem Azure-Portal registrieren möchten, können Sie den Parameter state verwenden, um Antworten in Ihrer Anwendung anhand verschiedener Anforderungen vom Azure AD B2C-Dienst zu unterscheiden. |
| login_hint | Nein | Kann zum Vorabausfüllen des Felds für den Anmeldenamen auf der Anmeldeseite verwendet werden. Weitere Informationen finden Sie unter Auffüllen des Anmeldenamens. |
| domain_hint | Nein | Bietet Hinweis für Azure AD B2C zu dem sozialen Netzwerk als Identitätsanbieter, das für die Anmeldung verwendet werden soll. Wenn ein gültiger Wert enthalten ist, wird der Benutzer direkt auf die Anmeldeseite des Identitätsanbieters geleitet. Weitere Informationen finden Sie unter Umleiten einer Anmeldung zu einem Anbieter sozialer Netzwerke. |
| Benutzerdefinierte Parameter | Nein | Benutzerdefinierte Parameter, die mit benutzerdefinierten Richtlinien verwendet werden können. Beispiele: URI für dynamischen Seiteninhalt oder OAuth2-Schlüssel-Wert-Parameter. |
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
| Parameter | BESCHREIBUNG |
|---|---|
| id_token | Das ID-Token, das die Anwendung angefordert hat. 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, wenn Sie response_type=code+id_token verwendet haben. Die Anwendung kann mit dem Autorisierungscode ein Zugriffstoken für eine Zielressource anfordern. Autorisierungscodes laufen in der Regel nach etwa zehn Minuten ab. |
| state | 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 in der Antwort identisch sind. |
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
| Parameter | BESCHREIBUNG |
|---|---|
| error | Ein Code, mit dem die Typen der auftretenden Fehler klassifiziert werden können. |
| error_description | Eine spezifische Fehlermeldung, mit der Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können. |
| state | 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 in der Antwort identisch sind. |
Ü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.
Hinweis
Die meisten Open-Source-Authentifizierungsbibliotheken validieren die JWT-Token für Ihre Anwendung. Wir empfehlen die Verwendung einer dieser Optionen, anstatt Ihre eigene Validierungslogik zu implementieren. Weitere Informationen finden Sie in der Übersicht über die Microsoft-Authentifizierungsbibliothek (MSAL) und unter Microsoft Identity Web-Authentifizierungsbibliothek.
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
iatundexp, 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
| Parameter | Erforderlich | BESCHREIBUNG |
|---|---|---|
| {tenant} | Ja | Name des 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 in der Abfragezeichenfolge hinzu, nicht im POST-Text. |
| client_id | Ja | Die Anwendungs-ID, die das Azure-Portal Ihrer Anwendung zugewiesen hat. |
| client_secret | Ja, in Web-Apps | Der geheime Schlüssel der Anwendung, der im Azure-Portal generiert wurde. Geheime Client-Schlüssel werden in diesem Flow für Web-App-Szenarien verwendet, in denen der Client einen geheimen Client-Schlüssel sicher speichern kann. Bei Szenarios mit nativen Apps (öffentlicher Client) können geheime Clientschlüssel nicht sicher gespeichert werden, daher werden sie nicht für diesen Flow verwendet. Wenn Sie einen geheimen Client-Schlüssel verwenden, ändern Sie ihn regelmäßig. |
| code | Ja | Der Autorisierungscode, den Sie am Anfang des Benutzerflows erhalten haben. |
| grant_type | Ja | Der Berechtigungstyp, der für den Autorisierungscodefluss authorization_code lauten muss. |
| redirect_uri | Nein | Der redirect_uri-Parameter der Anwendung, bei der Sie den Autorisierungscode erhalten haben. |
| scope | 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-Parametern an. Damit können Sie Token an die Back-End-Web-API ihrer Anwendung übermitteln, die durch dieselbe Anwendungs-ID wie der Client dargestellt wird. Der offline_access-Bereich gibt an, dass Ihre Anwendung ein Aktualisierungstoken für den dauerhaften Zugriff auf Ressourcen benötigt. |
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...",
}
| Parameter | BESCHREIBUNG |
|---|---|
| not_before | Der Zeitpunkt in Epochenzeit, ab dem das Token gültig ist. |
| token_type | Der Wert des Tokentyps. Bearer ist der einzige Typ, der unterstützt wird. |
| access_token | Das signierte JWT-Token, das Sie angefordert haben. |
| scope | Die gültigen Bereiche für das Token. |
| expires_in | Gibt an, wie lange das Zugriffstoken gültig ist (in Sekunden). |
| expires_on | Der Zeitpunkt, zu dem das Zugriffstoken ungültig wird (in Epochenzeit). |
| refresh_token | Ein Aktualisierungstoken von OAuth 2.0. Die Anwendung kann dieses Token verwenden, um nach Ablauf des aktuellen Tokens weitere Token zu erhalten. Mit Aktualisierungstoken kann der Zugriff auf Ressourcen für längere Zeit beibehalten werden. Der offline_access-Bereich muss sowohl für die Autorisierung als auch in den Tokenanforderungen verwendet werden, um ein Aktualisierungstoken zu erhalten. |
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"
}
| Parameter | BESCHREIBUNG |
|---|---|
| error | Ein Code, mit dem Typen der auftretenden Fehler klassifiziert werden können. |
| error_description | Eine Meldung, anhand derer Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können. |
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
| Parameter | Erforderlich | BESCHREIBUNG |
|---|---|---|
| {tenant} | Ja | Name des 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 in der Abfragezeichenfolge hinzu, nicht im POST-Text. |
| client_id | Ja | Die Anwendungs-ID, die das Azure-Portal Ihrer Anwendung zugewiesen hat. |
| client_secret | Ja, in Web-Apps | Der geheime Schlüssel der Anwendung, der im Azure-Portal generiert wurde. Geheime Client-Schlüssel werden in diesem Flow für Web-App-Szenarien verwendet, in denen der Client einen geheimen Client-Schlüssel sicher speichern kann. Bei Szenarios mit nativen Apps (öffentlicher Client) können geheime Clientschlüssel nicht sicher gespeichert werden, daher werden sie nicht für diesen Aufruf verwendet. Wenn Sie einen geheimen Client-Schlüssel verwenden, ändern Sie ihn regelmäßig. |
| grant_type | Ja | Der Berechtigungstyp, der für diesen Teil des Autorisierungscodeflusses refresh_token lauten muss. |
| refresh_token | Ja | Das ursprüngliche Aktualisierungstoken, das im zweiten Teil des Flows erhalten wurde. Der offline_access-Bereich muss sowohl für die Autorisierung als auch in den Tokenanforderungen verwendet werden, um ein Aktualisierungstoken zu erhalten. |
| redirect_uri | Nein | Der redirect_uri-Parameter der Anwendung, bei der Sie den Autorisierungscode erhalten haben. |
| scope | 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. Damit können Sie Token an die Back-End-Web-API Ihrer Anwendung 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 dauerhaften Zugriff auf Ressourcen benötigt. |
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"
}
| Parameter | BESCHREIBUNG |
|---|---|
| not_before | Der Zeitpunkt in Epochenzeit, ab dem das Token gültig ist. |
| token_type | Der Wert des Tokentyps. Bearer ist der einzige Typ, der unterstützt wird. |
| access_token | Das signierte JWT-Token, das angefordert wurde. |
| scope | Die gültigen Bereiche für das Token. |
| expires_in | Gibt an, wie lange das Zugriffstoken gültig ist (in Sekunden). |
| refresh_token | Ein Aktualisierungstoken von OAuth 2.0. Die Anwendung kann dieses Token verwenden, um nach Ablauf des aktuellen Tokens zusätzliche Token zu erhalten. Mit Aktualisierungstoken kann der Zugriff auf Ressourcen für längere Zeit beibehalten werden. |
| refresh_token_expires_in | Die Zeit, wie lange das Aktualisierungstoken gültig ist (in Sekunden) |
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",
}
| Parameter | BESCHREIBUNG |
|---|---|
| error | Ein Code, mit dem Typen der auftretenden Fehler klassifiziert werden können. |
| error_description | Eine Meldung, anhand derer Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können. |
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
| Parameter | Erforderlich | BESCHREIBUNG |
|---|---|---|
| {tenant} | Ja | Name Ihres Azure AD B2C-Mandanten Wenn Sie eine benutzerdefinierte Domäne verwenden, ersetzen Sie tenant.b2clogin.com durch Ihre Domäne, 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 an den Abmelde-Endpunkt als Hinweis bezüglich der aktuellen authentifizierten Sitzung des Endbenutzers mit dem Client übergeben werden soll. Der id_token_hint stellt sicher, dass der post_logout_redirect_uri eine registrierte Antwort-URL in Ihren Azure AD B2C-Anwendungseinstellungen darstellt. Weitere Informationen finden Sie unter Sichern der Umleitung beim Abmelden. |
| client_id | Nein* | Die Anwendungs-ID, die das Azure-Portal Ihrer Anwendung zugewiesen hat. *Dies ist erforderlich, wenn die Application-Isolation-SSO-Konfiguration verwendet wird und ID-Token erforderlich in der Abmeldeanforderung auf No festgelegt ist. |
| post_logout_redirect_uri | Nein | Die URL, an die der Benutzer nach erfolgreicher Abmeldung umgeleitet werden soll. Wenn sie nicht angegeben ist, gibt Azure AD B2C eine generische Nachricht an den Benutzer aus. Sofern Sie keinen id_token_hint angeben, sollten Sie diese URL nicht als Antwort-URL in Ihren Azure AD B2C-Anwendungseinstellungen registrieren. |
| state | Nein | Wenn Sie einen state-Parameter in der Autorisierungsanforderung einschließen, gibt der Autorisierungsserver denselben Wert in der Antwort an den post_logout_redirect_uri zurück. Die Anwendung sollte überprüfen, ob der state-Wert in der Anforderung und in der Antwort identisch ist. |
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.