Teilen über

Anmeldung für eine Single-Page-Webanwendung mit dem impliziten OAuth 2.0-Fluss 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.

Viele moderne Anwendungen verfügen über ein Einzelseiten-App-Front-End (SPA), das in erster Linie in JavaScript geschrieben wird. Häufig wird die App mit einem Framework wie React, Angular oder Vue.jsgeschrieben. SPAs und andere JavaScript-Apps, die hauptsächlich in einem Browser ausgeführt werden, haben einige zusätzliche Herausforderungen für die Authentifizierung:

  • Die Sicherheitsmerkmale dieser Apps unterscheiden sich von herkömmlichen serverbasierten Webanwendungen.

  • Viele Autorisierungsserver und Identitätsanbieter unterstützen keine corS-Anforderungen (Cross-Origin Resource Sharing).

  • Ganzseitige Browserumleitungen von der App können für die Benutzererfahrung invasiv sein.

Warnung

Microsoft empfiehlt, dass Sie nicht den impliziten Genehmigungs-Flow verwenden. Die empfohlene Methode zur Unterstützung von SPAs ist der OAuth 2.0-Autorisierungscodefluss (mit PKCE). Bestimmte Konfigurationen dieses Flows erfordern ein sehr hohes Maß an Vertrauen in die Anwendung und bergen Risiken, die in anderen Flows nicht vorhanden sind. Verwenden Sie diesen Flow nur, wenn kein anderer Flow verfügbar ist, der mehr Sicherheit bietet. Weitere Informationen finden Sie in den Sicherheitsaspekten mit dem impliziten Genehmigungsfluss.

Einige Frameworks, z. B. MSAL.js 1.x, unterstützen nur den impliziten Grant-Flow. In diesen Fällen unterstützt Azure Active Directory B2C (Azure AD B2C) den impliziten OAuth 2.0-Autorisierungserteilungsfluss. Der Fluss wird in Abschnitt 4.2 der OAuth 2.0-Spezifikation beschrieben. Im impliziten Fluss empfängt die App Token direkt vom Azure AD B2C-Autorisierungsendpunkt ohne Server-zu-Server-Austausch. Alle Authentifizierungslogik und Sitzungsverarbeitung erfolgen vollständig im JavaScript-Client mit einer Seitenumleitung oder einem Popupfeld.

Azure AD B2C erweitert den impliziten OAuth 2.0-Standardfluss auf mehr als einfache Authentifizierung und Autorisierung. Azure AD B2C führt den Richtlinienparameter ein. Mit dem Richtlinienparameter können Sie OAuth 2.0 verwenden, um Ihrer App Richtlinien hinzuzufügen, z. B. Registrierungs-, Anmelde- und Profilverwaltungsbenutzerflüsse. In den Beispiel-HTTP-Anforderungen in diesem Artikel verwenden wir {tenant}.onmicrosoft.com zur Veranschaulichung. Ersetzen Sie sie durch {tenant}den Namen Ihres Mandanten , wenn Sie einen haben. Außerdem müssen Sie einen Benutzerablauf erstellt haben.

Wir verwenden die folgende Abbildung, um den impliziten Anmeldefluss zu veranschaulichen. Jeder Schritt wird weiter unten im Artikel ausführlich beschrieben.

Swimlane-Diagramm, das den impliziten OpenID Connect-Fluss zeigt

Senden von Authentifizierungsanforderungen

Wenn Ihre Webanwendung den Benutzer authentifizieren und einen Benutzerfluss ausführen muss, leitet sie den Benutzer an den Endpunkt von /authorize Azure AD B2C weiter. Der Benutzer führt abhängig vom Benutzerablauf Aktionen aus.

In dieser Anforderung gibt der Client die Berechtigungen an, die er vom Benutzer im scope Parameter abrufen muss, und den auszuführenden Benutzerfluss. Um ein Gefühl für die Funktionsweise der Anforderung zu erhalten, versuchen Sie, die Anforderung in einen Browser einzufügen und auszuführen. Ersetzen:

  • {tenant} mit dem Namen Ihres Azure AD B2C-Mandanten.

  • 00001111-aaaa-2222-bbbb-3333cccc4444 mit der App-ID der Anwendung, die Sie in Ihrem Mandanten registriert haben.

  • {policy} mit dem Namen einer Richtlinie, die Sie in Ihrem Mandanten erstellt haben, zum Beispiel b2c_1_sign_in.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Die Parameter in der HTTP GET-Anforderung werden in der folgenden Tabelle erläutert.

Parameter Erforderlich BESCHREIBUNG
{tenant} Ja Name Ihres Azure AD B2C-Mandanten
{policy} Ja Der Name des Benutzerflusses, den Sie ausführen möchten. 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 Ja Die Anwendungs-ID, die dem Azure-Portal Ihrer Anwendung zugewiesen wurde.
Antworttyp Ja Muss id_token für die OpenID Connect-Anmeldung enthalten. Sie kann auch den Antworttyp tokenenthalten. Wenn Sie token nutzen, kann Ihre App sofort ein Zugriffstoken vom Autorisierungsendpunkt empfangen, ohne eine zweite Anforderung zu senden. Wenn Sie den token Antworttyp verwenden, muss der scope Parameter einen Bereich enthalten, der angibt, für welche Ressource das Token auszugeben ist.
Weiterleitungs-URI Nein Der Umleitungs-URI der App, in dem Authentifizierungsantworten gesendet und von der App empfangen werden können. Es muss genau mit einer der Umleitungs-URIs übereinstimmen, die Sie einer registrierten Anwendung im Portal hinzugefügt haben, mit der Ausnahme, dass sie URL-codiert sein muss.
Antwortmodus Nein Gibt die Methode an, die zum Senden des resultierenden Tokens an Ihre App verwendet werden soll. Verwenden Sie fragmentfür implizite Flüsse .
Umfang Ja Eine durch Leerzeichen getrennte Liste von Bereichen. Ein einzelner Bereichswert zeigt Microsoft Entra ID beide angeforderten Berechtigungen an. 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 Web-Apps optional. Sie gibt an, dass Ihre App ein Aktualisierungstoken für den langfristigen Zugriff auf Ressourcen benötigt.
Staat Nein Ein In der Anforderung enthaltener Wert, der auch in der Tokenantwort zurückgegeben wird. Dies kann eine Zeichenfolge aller Inhalte sein, die Sie verwenden möchten. In der Regel wird ein zufällig generierter eindeutiger Wert verwendet, um websiteübergreifende Anforderungsverfälschungsangriffe zu verhindern. Der Zustand wird auch verwendet, um Informationen zum Status des Benutzers in der App zu codieren, bevor die Authentifizierungsanforderung aufgetreten ist, z. B. die Seite, auf der sich der Benutzer befand, oder den Benutzerfluss, der ausgeführt wurde.
Nonce Ja Ein Wert, der in der Anforderung (generiert von der App) enthalten ist, die im resultierenden ID-Token als Anspruch enthalten ist. Die App kann diesen Wert dann überprüfen, um die Gefahr von Tokenwiedergabeangriffen zu vermindern. Normalerweise ist der Wert eine zufällige, eindeutige Zeichenfolge, die verwendet werden kann, um den Ursprung der Anforderung zu identifizieren.
prompt Nein Der Typ der Benutzerinteraktion, die erforderlich ist. Derzeit ist loginder einzige gültige Wert . Dieser Parameter zwingt den Benutzer, seine Anmeldeinformationen für diese Anforderung einzugeben. Einzelnes Sign-On hat keine Wirkung.

Dies ist der interaktive Teil des Ablaufs. Der Benutzer wird aufgefordert, den Workflow der Richtlinie abzuschließen. Möglicherweise muss der Benutzer seinen Benutzernamen und sein Kennwort eingeben, sich mit einer sozialen Identität anmelden, sich für ein lokales Konto registrieren oder eine andere Anzahl von Schritten ausführen. Benutzeraktionen hängen davon ab, wie der Benutzerablauf definiert ist.

Nachdem der Benutzer den Benutzerablauf abgeschlossen hat, gibt Azure AD B2C eine Antwort über das redirect_uri an Ihre App zurück. Sie verwendet die im response_mode Parameter angegebene Methode. Die Antwort entspricht genau den einzelnen Benutzeraktionsszenarien, unabhängig vom ausgeführten Benutzerablauf.

Erfolgreiche Antwort

Eine erfolgreiche Antwort, die response_mode=fragment und response_type=id_token+token verwendet, sieht wie folgt aus, mit Zeilenumbrüchen zur besseren Lesbarkeit:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
Parameter BESCHREIBUNG
Zugriffstoken Das Zugriffstoken, das die App von Azure AD B2C angefordert hat.
Token-Typ Der Wert des Token-Typs. Der einzige Typ, den Azure AD B2C unterstützt, ist Bearer.
expires_in Die Dauer der Gültigkeit des Zugriffstokens (in Sekunden).
Umfang Die Bereiche, für die das Token gültig ist. Sie können auch Bereiche verwenden, um Token für die spätere Verwendung zwischenzuspeichern.
id_token (Identitäts-Token) Das ID-Token, das die App angefordert hat. Sie können mit dem ID-Token die Identität des Benutzers überprüfen und eine Sitzung mit dem Benutzer beginnen. Weitere Informationen zu ID-Token und deren Inhalten finden Sie in der Azure AD B2C-Tokenreferenz.
Staat 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.

Fehlerantwort

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

GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
Parameter BESCHREIBUNG
Fehler Ein Code, der verwendet wird, um Fehlertypen zu klassifizieren, die auftreten.
Fehlerbeschreibung Eine spezifische Fehlermeldung, mit der Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können.
Staat 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.

Überprüfen des ID-Tokens

Das Empfangen 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 App. 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.

Viele Open-Source-Bibliotheken stehen für die Überprüfung von JWTs zur Verfügung, je nachdem, welche Sprache Sie verwenden möchten. Erwägen Sie, die verfügbaren Open-Source-Bibliotheken zu untersuchen, anstatt Ihre eigene Validierungslogik zu implementieren. Sie können die Informationen in diesem Artikel verwenden, um zu erfahren, wie Diese Bibliotheken ordnungsgemäß verwendet werden.

Azure AD B2C verfügt über einen OpenID Connect-Metadatenendpunkt. Eine App kann den Endpunkt verwenden, um Informationen zu Azure AD B2C zur Laufzeit abzurufen. Diese Informationen umfassen Endpunkte, Tokeninhalte und Tokensignaturschlüssel. Es gibt ein JSON-Metadatendokument für jeden Benutzerfluss in Ihrem Azure AD B2C-Mandanten. Das Metadatendokument für einen Benutzerfluss mit dem Namen b2c_1_sign_in innerhalb eines fabrikamb2c.onmicrosoft.com Mandanten 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 die jwks_uri. Der Wert für denselben Benutzerablauf wäre:

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

Um zu bestimmen, welcher Benutzerablauf zum Signieren eines ID-Tokens genutzt wurde und wo die Metadaten abgerufen werden sollen, können Sie eine der folgenden Optionen verwenden:

  • Der Benutzerflowname ist im acr-Anspruch in id_token enthalten. Informationen zum Analysieren der Ansprüche aus einem ID-Token finden Sie in der Azure AD B2C-Tokenreferenz.

  • Codieren Sie den Benutzerfluss im Wert des state Parameters, wenn Sie die Anforderung ausgeben. Decodieren Sie dann den state Parameter, um zu bestimmen, welcher Benutzerfluss verwendet wurde.

Nachdem Sie das Metadatendokument vom OpenID Connect-Metadatenendpunkt abgerufen haben, können Sie die öffentlichen RSA-256-Schlüssel (auf diesem Endpunkt) verwenden, um die Signatur des ID-Tokens zu überprüfen. Möglicherweise gibt es zu einem bestimmten Zeitpunkt mehrere Schlüssel an diesem Endpunkt, die jeweils durch eine kid identifiziert werden. Der Header der id_token enthält auch einen kid-Anspruch. Es gibt an, welche dieser Schlüssel zum Signieren des ID-Tokens verwendet wurde. Weitere Informationen, einschließlich Informationen zum Überprüfen von Token, finden Sie in der Azure AD B2C-Tokenreferenz.

Nachdem Sie die Signatur des ID-Tokens überprüft haben, müssen mehrere Ansprüche überprüft werden. Beispiel:

  • Überprüfen Sie den nonce-Anspruch, um Tokenwiedergabeangriffe 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 App ausgestellt wurde. Der Wert sollte die Anwendungs-ID Ihrer App sein.

  • Überprüfen Sie die iat- und exp-Ansprüche, um sicherzustellen, dass das ID-Token nicht abgelaufen ist.

In der OpenID Connect Core-Spezifikation werden mehrere weitere Überprüfungen beschrieben, die Sie ausführen sollten. Sie können auch zusätzliche Ansprüche je nach Szenario überprüfen. Einige allgemeine Überprüfungen umfassen:

  • Sicherstellen, dass sich der Benutzer oder die Organisation für die App registriert hat.

  • Sicherstellen, dass der Benutzer über die richtige Autorisierung und Berechtigungen verfügt.

  • Sicherstellen, dass eine bestimmte Stärke der Authentifizierung aufgetreten ist, z. B. mithilfe der mehrstufigen Microsoft Entra-Authentifizierung.

Weitere Informationen zu den Ansprüchen in einem ID-Token finden Sie in der Azure AD B2C-Tokenreferenz.

Nachdem Sie das ID-Token überprüft haben, können Sie eine Sitzung mit dem Benutzer beginnen. Verwenden Sie in Ihrer App die Ansprüche im ID-Token, um Informationen über den Benutzer abzurufen. Diese Informationen können für Anzeige, Datensätze, Autorisierung usw. verwendet werden.

Zugriffstoken erhalten

Wenn ihre Web-Apps nur Benutzerflüsse ausführen müssen, können Sie die nächsten Abschnitte überspringen. Die Informationen in den folgenden Abschnitten gelten nur für Web-Apps, die authentifizierte Aufrufe an eine Web-API ausführen müssen, die von Azure AD B2C selbst geschützt ist.

Nachdem Sie den Benutzer bei Ihrem SPA angemeldet haben, können Sie Zugriffstoken für das Aufrufen von Web-APIs erhalten, die durch die Microsoft Entra-ID gesichert sind. Auch wenn Sie bereits ein Token mithilfe des token Antworttyps erhalten haben, können Sie diese Methode verwenden, um Token für zusätzliche Ressourcen abzurufen, ohne den Benutzer erneut zur Anmeldung umzuleiten.

In einem typischen Web App-Fluss würden Sie eine Anforderung an den /token Endpunkt senden. Der Endpunkt unterstützt jedoch keine CORS-Anforderungen, sodass AJAX-Aufrufe zum Abrufen eines Aktualisierungstokens keine Option sind. Stattdessen können Sie den impliziten Fluss in einem ausgeblendeten HTML-iframe-Element verwenden, um neue Token für andere Web-APIs abzurufen. Hier ist ein Beispiel mit Zeilenumbrüchen für die Lesbarkeit:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
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 Muss id_token für die Anmeldung mittels OpenID Connect enthalten. Er kann auch den Antworttyp tokenenthalten. Wenn Sie hier verwenden token , kann Ihre App sofort ein Zugriffstoken vom autorisierungsendpunkt empfangen, ohne eine zweite Anforderung an den autorisierungsendpunkt zu senden. Wenn Sie den token Antworttyp verwenden, muss der scope Parameter einen Bereich enthalten, der angibt, für welche Ressource das Token auszugeben ist.
Weiterleitungs-URI Empfohlen Der Umleitungs-URI der App, in dem Authentifizierungsantworten gesendet und von der App empfangen werden können. Er muss genau mit einem der Umleitungs-URIs übereinstimmen, den Sie im Portal registriert haben – mit dem Unterschied, dass er URL-codiert sein muss.
Umfang Erforderlich Eine durch Leerzeichen getrennte Liste von Bereichen. Schließen Sie zum Abrufen von Token alle Bereiche ein, die Sie für die beabsichtigte Ressource benötigen.
Antwortmodus Empfohlen Gibt die Methode an, die verwendet wird, um das resultierende Token an Ihre App zurückzusenden. Verwenden Sie fragmentfür impliziten Fluss . Es können zwei weitere Modi angegeben werden, nämlich query und form_post, die jedoch im impliziten Fluss nicht funktionieren.
Staat Empfohlen Ein In der Anforderung enthaltener Wert, der in der Tokenantwort zurückgegeben wird. Dies kann eine Zeichenfolge aller Inhalte sein, die Sie verwenden möchten. In der Regel wird ein zufällig generierter eindeutiger Wert verwendet, um websiteübergreifende Anforderungsverfälschungsangriffe 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. Beispielsweise die Seite oder die Ansicht, auf der sich der Benutzer befand.
Nonce Erforderlich Ein in der Anforderung enthaltener Wert, der von der App generiert wird und als Anspruch im resultierenden ID-Token enthalten ist. Die App kann diesen Wert dann überprüfen, um die Gefahr von Tokenwiedergabeangriffen zu vermindern. Normalerweise ist der Wert eine zufällige, eindeutige Zeichenfolge, die den Ursprung der Anforderung identifiziert.
prompt Erforderlich Um Tokens in einem ausgeblendeten iFrame zu aktualisieren und abzurufen, verwenden Sie prompt=none, um sicherzustellen, dass der iframe nicht auf der Anmeldeseite hängen bleibt und sofort geladen wird.
Login-Hinweis Erforderlich Um Token in einem ausgeblendeten iFrame zu aktualisieren und abzurufen, schließen Sie den Benutzernamen des Benutzers in diesen Hinweis ein, um zwischen mehreren Sitzungen zu unterscheiden, die der Benutzer möglicherweise zu einem bestimmten Zeitpunkt hat. Sie können den Benutzernamen aus einer früheren Anmeldung extrahieren, indem Sie den preferred_username Anspruch verwenden (der profile Umfang ist erforderlich, um den preferred_username Anspruch zu erhalten).
domain_hint Erforderlich Kann consumers oder organizations sein. Um Token in einem ausgeblendeten iframe zu aktualisieren und abzurufen, schließen Sie den domain_hint Wert in die Anforderung ein. Extrahieren Sie den tid Anspruch aus dem ID-Token einer früheren Anmeldung, um zu bestimmen, welcher Wert verwendet werden soll (der profile Bereich ist erforderlich, um den tid Anspruch zu erhalten). Wenn der tid Anspruchswert lautet 9188040d-6c67-4c5b-b112-36a304b66dad, verwenden Sie domain_hint=consumers. Verwenden Sie andernfalls domain_hint=organizations.

Durch Festlegen des prompt=none Parameters ist diese Anforderung entweder erfolgreich oder schlägt sofort fehl und kehrt zur Anwendung zurück. Eine erfolgreiche Antwort wird über den Umleitungs-URI mithilfe der im response_mode Parameter angegebenen Methode an Ihre App gesendet.

Erfolgreiche Antwort

Eine erfolgreiche Antwort mit response_mode=fragment sieht wie in diesem Beispiel aus:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
Parameter BESCHREIBUNG
Zugriffstoken Das Token, das die App angefordert hat.
Token-Typ Als Tokentyp wird immer „Bearer“ verwendet.
Staat 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.
expires_in Die Gültigkeitsdauer des Zugriffstokens (in Sekunden).
Umfang Die Bereiche, für die das Zugriffstoken gültig ist.

Fehlerantwort

Fehlerantworten können auch an den Umleitungs-URI gesendet werden, damit sie von der App entsprechend behandelt werden können. Für prompt=none, sieht ein erwarteter Fehler wie in diesem Beispiel aus:

GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
Parameter BESCHREIBUNG
Fehler Eine Fehlercodezeichenfolge, die verwendet werden kann, um Fehlertypen zu klassifizieren, die auftreten. 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.

Wenn Sie diesen Fehler in der IFrame-Anforderung erhalten, muss sich der Benutzer erneut anmelden, um ein neues Token abzurufen.

Aktualisierungstoken

ID-Token und Zugriffstoken laufen beide nach kurzer Zeit ab. Ihre App muss darauf vorbereitet sein, diese Token regelmäßig zu aktualisieren. Implizite Flüsse erlauben es Ihnen aus Sicherheitsgründen nicht, ein Aktualisierungstoken abzurufen. Verwenden Sie zum Aktualisieren eines tokentyps den impliziten Fluss in einem ausgeblendeten HTML-iframe-Element. In der Autorisierungsanforderung ist der prompt=none Parameter enthalten. Um einen neuen id_token-Wert zu erhalten, achten Sie darauf, response_type=id_token und scope=openid zu verwenden, sowie einen nonce-Parameter hinzuzufügen.

Senden einer Abmeldeanforderung

Wenn Sie den Benutzer bei der App abmelden möchten, leiten Sie den Benutzer an den Abmeldungsendpunkt von Azure AD B2C um. Anschließend können Sie die Sitzung des Benutzers in der App löschen. Wenn Sie den Benutzer nicht umleiten, kann er möglicherweise erneut mit Ihrer App authentifiziert werden, ohne seine Anmeldeinformationen erneut einzugeben, da er über eine gültige Single Sign-On-Sitzung mit Azure AD B2C verfügt.

Sie können den Benutzer einfach auf end_session_endpoint umleiten, das im selben OpenID Connect-Metadatendokument aufgeführt ist, das unter Validierung des ID-Tokens beschrieben ist. Beispiel:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
Parameter Erforderlich BESCHREIBUNG
{tenant} Ja Name Ihres Azure AD B2C-Mandanten.
{policy} Ja Der Benutzerfluss, den Sie verwenden möchten, um den Benutzer bei Ihrer Anwendung abzumelden. Dies muss derselbe Benutzerfluss sein, den die App zum Anmelden des Benutzers verwendet hat.
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.
Staat Nein 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.

Hinweis

Durch die Weiterleitung von Benutzenden zu end_session_endpoint wird der SSO-Status der Benutzenden in Azure AD B2C teilweise aufgehoben. Der Nutzer wird jedoch nicht von der Sitzung des sozialen Identitätsanbieters abgemeldet. Wenn der Benutzer während einer nachfolgenden Anmeldung denselben Identitätsanbieter auswählt, wird der Benutzer erneut authentifiziert, ohne seine Anmeldeinformationen einzugeben. Wenn sich ein Benutzer bei Ihrer Azure AD B2C-Anwendung abmelden möchte, bedeutet dies nicht unbedingt, dass er sich vollständig von ihrem Facebook-Konto abmelden möchte. Bei lokalen Konten wird die Sitzung des Benutzers jedoch ordnungsgemäß beendet.

Nächste Schritte

Sehen Sie sich das Codebeispiel an: Anmelden mit Azure AD B2C in einem JavaScript SPA.

  • Last updated on