Microsoft Identity Platform und der OAuth 2.0-Flow für die implizite Genehmigung

  • Artikel

Microsoft Identity Platform unterstützt den impliziten OAuth 2.0-Genehmigungsflow, der in der OAuth 2.0-Spezifikation beschrieben ist. Das definierende Merkmal der impliziten Genehmigung ist, dass Token (ID-Token oder Zugriffstoken) nicht über den Tokenendpunkt, sondern direkt über den Autorisierungsendpunkt zurückgegeben werden. Dies wird häufig im Rahmen des Autorisierungscodeflows genutzt und als „hybrider Flow“ bezeichnet. Hierbei wird das ID-Token bei der Autorisierungsanforderung zusammen mit einem Autorisierungscode abgerufen.

In diesem Artikel erfahren Sie, wie Sie direkt für das Protokoll in Ihrer Anwendung programmieren, um Token von Microsoft Entra ID anzufordern. Es wird stattdessen empfohlen, ggf. die unterstützten Microsoft Authentication Libraries (MSAL) zu verwenden, um Token zu erhalten und gesicherte Web-APIs aufzurufen. Eine Liste der Codebeispiele, die MSAL verwenden, finden Sie in den Codebeispielen der Microsoft Identity Platform.

Warnung

Microsoft empfiehlt, dass Sie nicht den impliziten Genehmigungs-Flow verwenden. In den meisten Szenarien sind sicherere Alternativen verfügbar und werden daher empfohlen. 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.

Protokolldiagramm

Im folgenden Diagramm wird gezeigt, wie der gesamte implizite Anmeldeflow aussieht. In den folgenden Abschnitten wird jeder Schritt im Detail beschrieben.

Abbildung des impliziten Anmeldevorgangs.

Geeignete Szenarien für die implizite OAuth2-Genehmigung

Die implizite Genehmigung ist nur für den ersten interaktiven Teil Ihres Anmeldevorgangs zuverlässig, bei dem das Fehlen der Drittanbietercookies Ihre Anwendung nicht beeinträchtigt. Diese Einschränkung bedeutet, dass Sie diesen Ansatz ausschließlich im Rahmen des hybriden Flows verwenden sollten, bei dem Ihre Anwendung einen Code und ein Token vom Autorisierungsendpunkt anfordert. In einem hybriden Flow erhält Ihre Anwendung einen Code, der gegen ein Aktualisierungstoken eingelöst werden kann, wodurch die Gültigkeit der Anmeldesitzung Ihrer App erhalten bleibt.

Empfohlene Verwendung des Autorisierungscodeflows

Da einige Browser die Unterstützung für Cookies von Drittanbietern entfernen, ist der implizite Genehmigungsflow keine geeignete Authentifizierungsmethode mehr. Da die Funktionen für einmaliges Anmelden im Hintergrund des Flows für die implizite Genehmigung ohne Drittanbietercookies nicht funktionieren, tritt bei Anwendungen ein Fehler auf, wenn diese ein neues Token abrufen. Wir empfehlen dringend, für alle neuen Anwendungen anstelle des Flows für die implizite Genehmigung den Autorisierungscodeflow zu verwenden, für den jetzt Single-Page-Apps unterstützt werden. Vorhandene Single-Page-Apps sollten auch zum Autorisierungscodeflow migriert werden.

Sicherheitsbedenken beim impliziten Genehmigungsfluss

Der implizite Genehmigungsfluss ist für herkömmliche Webanwendungen vorgesehen, bei denen der Server die Kontrolle über die sichere Verarbeitung von POST-Daten hat. Es gibt zwei Hauptmethoden zum Bereitstellen von Token mit dem impliziten Genehmigungsfluss: wo response_mode als URL-Fragment oder als Abfrageparameter (mit form POST und GET ) zurückgegeben wird. Beim impliziten Fluss mit response_mode=form_post wird das Token sicher über ein HTML-Formular POST an die Redirect-URI des Kunden übermittelt. Diese Methode stellt sicher, dass das Token nicht im URL-Fragment verfügbar gemacht wird, was wiederum das Risiko eines Token-Lecks durch den Browserverlauf oder Referrer-Header vermeidet.

Die Sicherheitsbedenken hinsichtlich des impliziten Datenflusses entstehen, wenn die Token mit response_mode=fragment geliefert werden. Das URL-Fragment ist der Teil der URL, der nach dem #-Symbol kommt und nicht an den Server gesendet wird, wenn der Browser eine neue Seite anfordert, sondern für das im Browser laufende JavaScript verfügbar ist. Das bedeutet, dass das Token jedem auf der Seite laufenden JavaScript ausgesetzt ist, was ein Sicherheitsrisiko darstellen kann, wenn die Seite Skripte von Drittanbietern enthält. Diese Sicherheitsbedenken für Token in SPAs gelten auch nicht für den impliziten Fluss mit form POST.

Wann sollten Sie zulassen, dass ein Zugriffstoken oder ein ID-Token ausgegeben wird, wenn dies mithilfe des impliziten Genehmigungs- oder Hybridflows angefordert wird?

Der implizite Genehmigungs- und Hybridflow ist nicht so sicher wie andere OAuth-Flows. Sofern nicht unbedingt erforderlich, sollten Sie es nicht zulassen, dass ein Zugriffs- oder ID-Token ausgegeben wird, wenn dies mithilfe des impliziten Genehmigungs- oder Hybridflows in Ihrer App-Registrierung angefordert wird. Wenn Sie (oder Ihr Entwicklerteam) in Ihrer Anwendung zum Implementieren von Authentifizierung und Autorisierung MSAL verwenden, muss keines der Felder aktiviert werden.

Wenn Sie (oder Ihre Entwickler) MSAL jedoch nicht in Ihrer Anwendung verwenden, zeigt die folgende Tabelle, wann Zugriffstoken oder ID-Token aktiviert werden sollten.

Art der Anwendung, die Sie erstellen Token, die Sie in der App-Registrierung aktivieren sollten
Eine SPA (Single-Page-Webanwendung), die nicht den Autorisierungscodeflow mit PKCE verwendet Zugriffstoken und ID-Token
Eine Web- oder Single-Page-Webanwendung, die eine Web-API über JavaScript mithilfe eines impliziten Flows aufruft Zugriffstoken und ID-Token
Eine ASP.NET Core Web App und andere Web-Apps, die hybride Authentifizierung verwenden ID-Token

Senden der Anmeldeanforderung

Zur anfänglichen Anmeldung der Benutzenden bei Ihrer App können Sie eine OpenID Connect-Authentifizierungsanforderung senden und ein id_token von Microsoft Identity Platform abrufen.

Wichtig

Um ein ID-Token und/oder ein Zugriffstoken erfolgreich anfordern zu können, muss für die App-Registrierung im Microsoft Entra Admin Center unter „App-Registrierungen“ der entsprechende Flow zur impliziten Genehmigung aktiviert sein. Wählen Sie hierzu im Abschnitt Implizite Genehmigung und Hybridflows die Optionen ID-Token und Zugriffstoken aus. Wenn sie nicht aktiviert ist, wird ein Fehler des Typs unsupported_response zurückgegeben:

The provided value for the input parameter 'response_type' is not allowed for this client. Expected value is 'code'

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345
&nonce=678910
Parameter Typ Beschreibung
tenant erforderlich Mit dem {tenant}-Wert im Pfad der Anforderung kann festgelegt werden, welche Benutzer sich bei der Anwendung anmelden können. Zulässige Werte sind common, organizations, consumers und Mandantenbezeichner. Weitere Informationen finden Sie in den Grundlagen zu Protokollen. Wichtig: In Gastszenarien, in denen Sie einen Benutzer aus einem Mandanten bei einem anderen Mandanten anmelden, müssen Sie die Mandanten-ID angeben, um ihn beim Ressourcenmandanten ordnungsgemäß anmelden zu können.
client_id erforderlich Die Anwendungs-ID (Client-ID), die Ihrer App auf der Seite „App-Registrierungen“ im Microsoft Entra Admin Center zugewiesen ist.
response_type erforderlich Muss das id_token für die OpenID Connect-Anmeldung enthalten. Es kann auch token als response_type enthalten sein. Mithilfe von token kann Ihre App ein Zugriffstoken direkt vom Autorisierungsendpunkt abrufen, ohne dass eine zweite Anforderung an den Autorisierungsendpunkt erforderlich ist. Wenn Sie den Antworttyp token verwenden, muss der scope-Parameter einen Bereich enthalten, der angibt, für welche Ressource das Token ausgestellt wird (z. B. user.read in Microsoft Graph). Er kann anstelle von token auch code enthalten, damit ein Autorisierungscode für die Verwendung im Autorisierungscodeflow bereitgestellt wird. Diese id_token+code-Antwort wird manchmal als Hybridflow bezeichnet.
redirect_uri empfohlen 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 Microsoft Entra Admin Center registriert haben, allerdings muss er als URL codiert sein.
scope erforderlich Eine durch Leerzeichen getrennte Liste von Bereichen. Für OpenID Connect (id_tokens) muss der Bereich openid enthalten sein, der auf der Zustimmungsbenutzeroberfläche die Anmeldeberechtigung ergibt. Optional können Sie auch die Bereiche email und profile einschließen, um Zugriff auf zusätzliche Benutzerdaten zu erhalten. Sie können in diese Anforderung auch andere Bereiche aufnehmen, um die Zustimmung für verschiedene Ressourcen anzufordern, wenn ein Zugriffstoken angefordert wird.
response_mode empfohlen Gibt die Methode an, die zum Senden des resultierenden Tokens zurück an Ihre App verwendet werden soll. Der Standardwert nur für ein Zugriffstoken ist query, aber fragment, wenn die Anforderung ein „id_token“ enthält. Aus Sicherheitsgründen wird empfohlen, form_post für den impliziten Fluss zu verwenden, um sicherzustellen, dass das Token nicht im URL-Fragment offengelegt wird.
state empfohlen Ein in der Anfrage enthaltener Wert wird auch in der Token-Antwort zurückgegeben. 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 verwendet, um Informationen über den Status des Benutzers in der App zu codieren, bevor die Authentifizierungsanforderung aufgetreten ist, z. B. Informationen zu der Seite oder Ansicht, die der Benutzer besucht hat.
nonce erforderlich Ein Wert in der Anforderung, der von der App generiert wird und im resultierenden ID-Token als Anspruch enthalten ist. Die App kann diesen Wert dann überprüfen, um die Gefahr von Tokenwiedergabeangriffen zu vermindern. Der Wert ist in der Regel eine zufällige, eindeutige Zeichenfolge, die zur Identifizierung des Ursprungs der Anforderung verwendet werden kann. Nur erforderlich, wenn ein id_token angefordert wird.
prompt optional Gibt den Typ der erforderlichen Benutzerinteraktion an. Die einzigen gültigen Werte sind gegenwärtig login, none, select_account und consent. prompt=login zwingt den Benutzer, die Anmeldeinformationen bei dieser Anforderung einzugeben. Einmaliges Anmelden ist dadurch nicht möglich. prompt=none stellt das Gegenteil dar. Hiermit wird sichergestellt, dass den Benutzer*innen keinerlei interaktive Eingabeaufforderung angezeigt wird. Wenn die Anforderung nicht per SSO im Hintergrund abgeschlossen werden kann, gibt Microsoft Identity Platform einen Fehler zurück. prompt=select_account sendet den Benutzer an eine Kontoauswahl, in der alle in der Sitzung gespeicherten Konten angezeigt werden. prompt=consent löst nach der Anmeldung des Benutzers das OAuth-Zustimmungsdialogfeld aus, in dem der Benutzer aufgefordert wird, der App Berechtigungen zu gewähren.
login_hint optional Sie können diesen Parameter verwenden, um das Feld für den Benutzernamen und die E-Mail-Adresse auf der Anmeldeseite vorab für die Benutzerin oder den Benutzer auszufüllen, wenn der Benutzername im Vorfeld bekannt ist. Apps verwenden diesen Parameter oft während der erneuten Authentifizierung, nachdem sie den optionalen Anspruch login_hintbereits aus einer vorherigen Anmeldung extrahiert haben.
domain_hint optional Wenn dies der Fall ist, wird der E-Mail-basierte Ermittlungsprozess, den der Benutzer auf der Anmeldeseite durchläuft, übersprungen, was zu einer verbesserten Benutzerfreundlichkeit führt. Dieser Parameter wird häufig für branchenspezifische Apps verwendet, die mit nur einem Mandanten betrieben werden. Hierbei wird in einem bestimmten Mandanten ein Domänenname angegeben, und der Benutzer wird an den Verbundanbieter für diesen Mandanten weitergeleitet. Dieser Hinweis verhindert, dass sich Gäste nicht bei der Anwendung anmelden können, und er schränkt die Nutzung von Cloudanmeldeinformationen wie FIDO ein.

An dieser Stelle wird der Benutzer aufgefordert, seine Anmeldeinformationen einzugeben und die Authentifizierung abzuschließen. Microsoft Identity Platform stellt sicher, dass der Benutzer den Berechtigungen zugestimmt hat, die im Abfrageparameter scope angegeben sind. Wenn der Benutzer keiner Berechtigung zugestimmt hat, wird er dazu aufgefordert, den erforderlichen Berechtigungen zuzustimmen. Weitere Informationen finden Sie unter Berechtigungen, Zustimmung und mehrinstanzenfähigen Apps.

Sobald sich der Benutzer authentifiziert und seine Zustimmung erteilt hat, gibt Microsoft Identity Platform mithilfe der im Parameter response_mode festgelegten Methode eine Antwort über den angegebenen redirect_uri an Ihre App zurück.

Erfolgreiche Antwort

Eine erfolgreiche Antwort mithilfe von response_mode=fragment und response_type=id_token+code sieht wie folgt aus, wobei die Zeilenumbrüche der Lesbarkeit dienen:

GET https://localhost/myapp/#
code=0.AgAAktYV-sfpYESnQynylW_UKZmH-C9y_G1A
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=12345
Parameter Beschreibung
code Ist enthalten, wenn code in response_type enthalten ist. Dies ist ein Autorisierungscode, der im Autorisierungscodeflow verwendet werden kann.
access_token Ist enthalten, wenn token in response_type enthalten ist. Das von der App angeforderte Zugriffstoken. Das Zugriffstoken sollte nicht decodiert oder anderweitig untersucht werden, es sollte als nicht transparente Zeichenfolge behandelt werden.
token_type Ist enthalten, wenn token in response_type enthalten ist. Dies ist immer Bearer.
expires_in Ist enthalten, wenn token in response_type enthalten ist. Gibt die Anzahl der Sekunden an, in denen das Token für die Zwischenspeicherung gültig ist.
scope Ist enthalten, wenn token in response_type enthalten ist. Gibt einen oder mehrere Bereiche an, für die das access_token gültig ist. Möglicherweise sind nicht alle angeforderten Bereiche enthalten, wenn sie auf den Benutzer nicht anwendbar waren. Beispielsweise werden reine Microsoft Entra-Bereiche angefordert, wenn Sie sich mit einem persönlichen Konto anmelden.
id_token Ein signiertes JSON Web Token (JWT). Die App kann die Segmente dieses Tokens entschlüsseln, um Informationen über den Benutzer, der sich angemeldet hat, anzufordern. Die App kann die Werte zwischenspeichern und anzeigen, aber sie sollte sich nicht auf sie verlassen, wenn es um Autorisierung oder Sicherheitsbegrenzungen geht. Weitere Informationen zu ID-Token finden Sie unter id_token reference.
Hinweis: Wird nur bei Anforderung des Bereichs openid und bei Auswahl von id_tokens für response_type bereitgestellt.
state Wenn ein Statusparameter in der Anforderung enthalten ist, sollte der gleiche Wert in der Antwort angezeigt werden. Die App sollte bestätigen, dass die state-Werte in der Anforderung und der Antwort identisch sind.

Warnung

Versuchen Sie nicht, Token für eine API zu überprüfen oder zu lesen, die Sie nicht besitzen, einschließlich der Token in Ihrem Code in diesem Beispiel. Token für Microsoft-Dienste können ein spezielles Format verwenden, das nicht als JWT überprüft und auch für Consumerbenutzer (Microsoft-Konto) verschlüsselt werden kann. Das Lesen von Token ist zwar ein nützliches Debug- und Lerntool, aber integrieren Sie weder Abhängigkeiten davon in Ihren Code noch setzen Sie Einzelheiten über Token voraus, die nicht für eine von Ihnen kontrollierte API gelten.

Fehlerantwort

Fehlerantworten können auch an den redirect_uri gesendet werden, damit die App diese angemessen behandeln kann:

GET https://localhost/myapp/#
error=access_denied
&error_description=the+user+canceled+the+authentication
Parameter Beschreibung
error Eine Fehlercodezeichenfolge, die verwendet werden kann, um unterschiedliche Arten auftretender Fehler zu klassifizieren und um auf Fehler zu reagieren.
error_description Eine spezifische Fehlermeldung, mit der Entwickler die Hauptursache eines Authentifizierungsfehlers identifizieren können.

Automatisches Abrufen von Token

Nachdem sich Ihr Benutzer bei Ihrer einseitigen Anwendung angemeldet hat, können Sie Zugriffstoken zum Aufrufen der von der Microsoft Identity Platform gesicherten Web-APIs automatisch abrufen, z. B. Microsoft Graph. Auch wenn Sie mithilfe des Antworttyps token bereits ein Token erhalten haben, können Sie diese Methode zum Abrufen von Token für zusätzliche Ressourcen verwenden, ohne den Benutzer zur erneuten Anmeldung umzuleiten.

Wichtig

Dieser Teil des impliziten Flows funktioniert für Ihre Anwendung wahrscheinlich nicht. Der Grund ist, dass er aufgrund der standardmäßigen Entfernung von Drittanbietercookies für unterschiedliche Browser genutzt wird. Für Chromium-basierte Browser funktioniert dies zwar noch, wenn diese nicht im Inkognitomodus verwendet werden, aber Entwickler sollten die Nutzung dieses Teils des Flows trotzdem überdenken. In Browsern, die keine Drittanbietercookies unterstützen, erhalten Sie eine Fehlermeldung mit dem Hinweis, dass keine Benutzer angemeldet sind, da die Sitzungscookies der Anmeldeseite vom Browser entfernt wurden.

Im herkömmlichen OpenID Connect/OAuth-Fluss senden Sie dazu eine Anforderung an den Microsoft Identity Platform-Endpunkt /token. Sie können die Anforderung in einem ausgeblendeten IFrame senden, um neue Token für andere Web-APIs zu erhalten:

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444&response_type=token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
&response_mode=fragment
&state=12345
&nonce=678910
&prompt=none
&login_hint=myuser@mycompany.com

Weitere Informationen zu den Abfrageparametern in der URL finden Sie unter Senden der Anmeldeanforderung.

Tipp

Versuchen Sie, die folgende Anfrage per Copy & Paste in einen Browser-Tab einzufügen und dabei ein echtes client_id und username aus Ihrer App-Registrierung zu verwenden. So können Sie die stille Token-Anforderung in Aktion sehen.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={your-client-id}&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read&response_mode=fragment&state=12345&nonce=678910&prompt=none&login_hint={username}

Beachten Sie, dass dies auch in Browsern ohne Unterstützung von Drittanbietercookies funktioniert. Der Grund ist, dass die Eingabe direkt in einer Browserleiste erfolgt (im Gegensatz zum Öffnen in einem IFrame).

Dank des Parameters prompt=none ist diese Anforderung entweder erfolgreich oder sie schlägt direkt fehl und kehrt zu Ihrer Anwendung zurück. Die Antwort wird an Ihre App an den angegebenen Umleitungs-URI (redirect_uri) gesendet. Dabei wird die im Parameter response_mode angegebene Methode verwendet.

Erfolgreiche Antwort

Eine erfolgreiche Antwort mit response_mode=fragment sieht wie folgt aus:

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=12345
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fdirectory.read
Parameter Beschreibung
access_token Ist enthalten, wenn token in response_type enthalten ist. Das von der Anwendung angeforderte Zugriffstoken, in diesem Fall für Microsoft Graph. Das Zugriffstoken sollte nicht decodiert oder anderweitig untersucht werden, es sollte als nicht transparente Zeichenfolge behandelt werden.
token_type Dies ist immer Bearer.
expires_in Gibt die Anzahl der Sekunden an, in denen das Token für die Zwischenspeicherung gültig ist.
scope Gibt einen oder mehrere Bereiche an, für die das Zugriffstoken gültig ist. Umfasst eventuell nicht alle angeforderten Bereiche, wenn sie nicht auf den Benutzer anwendbar waren (Wenn nur Microsoft Entra-Bereiche angefordert werden, wenn ein persönliches Konto zur Anmeldung verwendet wird).
id_token Ein signiertes JSON Web Token (JWT). Ist enthalten, wenn id_token in response_type enthalten ist. Die App kann die Segmente dieses Tokens entschlüsseln, um Informationen über den Benutzer, der sich angemeldet hat, anzufordern. Die App kann die Werte zwischenspeichern und anzeigen, aber sie sollte sich nicht auf sie verlassen, wenn es um Autorisierung oder Sicherheitsbegrenzungen geht. Weitere Informationen zu ID-Token (id_token) finden Sie in der id_token-Referenz.
Hinweis: Wird nur bei Anforderung des openid-Bereichs bereitgestellt.
state Wenn ein Statusparameter in der Anforderung enthalten ist, sollte der gleiche Wert in der Antwort angezeigt werden. Die App sollte bestätigen, dass die state-Werte in der Anforderung und der Antwort identisch sind.

Fehlerantwort

Fehlerantworten können auch an den redirect_uri gesendet werden, damit die App diese angemessen behandeln kann. Wenn prompt=none, ist ein erwarteter Fehler:

GET https://localhost/myapp/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
Parameter Beschreibung
error Eine Fehlercodezeichenfolge, die verwendet werden kann, um unterschiedliche Arten auftretender Fehler zu klassifizieren und um auf Fehler zu reagieren.
error_description Eine spezifische Fehlermeldung, mit der Entwickler 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. Diesen Fall können Sie so behandeln, wie es für Ihre Anwendung am sinnvollsten ist.

Aktualisieren von Token

Die implizite Genehmigung stellt keine Aktualisierungstoken bereit. Sowohl ID-Token als auch Zugriffstoken laufen nach kurzer Zeit ab, daher muss Ihre App in der Lage sein, diese Token regelmäßig zu aktualisieren. Um beide Arten von Token zu aktualisieren, können Sie dieselbe versteckte Iframe-Anforderung durchführen, die zuvor beschrieben wurde, wobei Sie den prompt=none-Parameter verwenden, um das Verhalten der Identitätsplattform zu steuern. Wenn Sie ein neues ID-Token erhalten möchten, verwenden Sie unbedingt id_token in response_type und scope=openid sowie einen nonce-Parameter.

In Browsern, für die keine Drittanbietercookies unterstützt werden, führt dies zu einer Fehlermeldung mit dem Hinweis, dass kein Benutzer angemeldet ist.

Senden einer Abmeldeanforderung

Der end_session_endpoint von OpenID Connect ermöglicht Ihrer App das Senden einer Anforderung an Microsoft Identity Platform zum Beenden einer Benutzersitzung und zum Löschen der von Microsoft Identity Platform festgelegten Cookies. Um einen Benutzer vollständig von einer Webanwendung abzumelden, muss Ihre App ihre eigene Sitzung mit dem Benutzer beenden (in der Regel durch Löschen eines Tokencaches oder von Cookies) und dann den Browser zu folgender Adresse umleiten:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/logout?post_logout_redirect_uri=https://localhost/myapp/
Parameter Typ Beschreibung
tenant erforderlich Mit dem {tenant}-Wert im Pfad der Anforderung kann festgelegt werden, welche Benutzer sich bei der Anwendung anmelden können. Zulässige Werte sind common, organizations, consumers und Mandantenbezeichner. Weitere Informationen finden Sie in den Grundlagen zu Protokollen.
post_logout_redirect_uri empfohlen Die URL, zu der der Benutzer nach erfolgreicher Abmeldung umgeleitet werden soll. Dieser Wert muss einem der Umleitung-URIs entsprechen, die für die Anwendung registriert sind. Wenn keine Angabe erfolgt, wird dem Benutzer von Microsoft Identity Platform eine allgemeine Meldung angezeigt.

Siehe auch