Microsoft Identity Platform und der OAuth 2.0-Flow für die implizite Genehmigung
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. Sehen Sie sich auch die Beispiel-Apps an, die MSAL verwenden.
Tipp
Führen Sie diese Anforderung und weitere Funktionen in Postman aus. Vergessen Sie nicht, Token und IDs zu ersetzen.
Empfohlene Verwendung des Autorisierungscodeflows
Da geplant ist, Drittanbietercookies aus Browsern zu entfernen, ist der Flow für die implizite Genehmigung 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.
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.
Protokolldiagramm
Im folgenden Diagramm wird gezeigt, wie der gesamte implizite Anmeldeflow aussieht. In den folgenden Abschnitten wird jeder Schritt im Detail beschrieben.
Senden der Anmeldeanforderung
Zur anfänglichen Anmeldung des Benutzers 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=535fb089-9ff3-47b6-9bfb-4f1264799865
&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 |
required | 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 können. Er muss genau mit einem der Umleitungs-URIs übereinstimmen, die Sie im Portal registriert haben. Außerdem muss er 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 |
optional | 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 „Abfrage“, aber „Fragment“, wenn die Anforderung ein „id_token“ enthält. |
state |
empfohlen | Ein in der Anforderung enthaltener Wert, der auch in der Antwort zurückgegeben wird. 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 erzeugt 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 ist genau das Gegenteil: Dieser Wert stellt sicher, dass dem Benutzer keine 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 den Benutzer auszufüllen, wenn dessen Benutzername im Vorfeld bekannt ist. Apps verwenden diesen Parameter oft während der erneuten Authentifizierung, nachdem sie den optionalen Anspruchlogin_hint bereits aus einer vorherigen Anmeldung extrahiert haben. |
domain_hint |
optional | Wenn dieser Parameter vorhanden ist, wird der E-Mail-basierte Ermittlungsvorgang übersprungen, den der Benutzer auf der Anmeldeseite durchläuft, und so die Benutzerfreundlichkeit verbessert. Dieser Parameter wird häufig bei branchenspezifischen Apps verwendet, die in einem einzigen Mandanten ausgeführt werden, in dem sie einen Domänennamen innerhalb eines bestimmten Mandanten bereitstellen und so den Benutzer zum Verbundanbieter für diesen Mandanten weiterleiten. 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. |
Zu diesem Zeitpunkt wird der Benutzer dazu aufgefordert, seine Anmeldeinformationen einzugeben und die Authentifizierung abzuschließen. Microsoft Identity Platform stellt auch sicher, dass der Benutzer den Berechtigungen zugestimmt hat, die im scope
-Abfrageparameter 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. Der Wert für dieses Feld ist immer Bearer . |
expires_in |
Ist enthalten, wenn token in response_type enthalten ist. Gibt für die Zwischenspeicherung den Gültigkeitszeitraum des Tokens in Sekunden an. |
scope |
Ist enthalten, wenn token in response_type enthalten ist. Gibt die Bereiche an, für die das Zugriffstoken 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 Anwendung sollte überprüfen, ob die Statuswerte in der Anforderung und in 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
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.
Nachdem Sie den Benutzer bei der Single-Page-App angemeldet haben, 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.
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=535fb089-9ff3-47b6-9bfb-4f1264799865
&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
Fügen Sie mit Copy & Paste die folgende Anforderung in eine Browserregisterkarte ein. (Vergessen Sie dabei nicht, den Wert login_hint
durch den richtigen Wert für den Benutzer zu ersetzen.)
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=535fb089-9ff3-47b6-9bfb-4f1264799865&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={your-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 |
Der Wert für dieses Feld ist immer Bearer . |
expires_in |
Gibt die Anzahl der Sekunden an, in denen das Token für die Zwischenspeicherung gültig ist. |
scope |
Gibt die Bereiche an, für die das Zugriffstoken gültig ist. Umfasst eventuell nicht alle angeforderten Bereiche, wenn sie nicht auf den Benutzer anwendbar waren (im Fall von reinen Microsoft Entra-Bereichen, die angefordert werden, wenn ein persönliches Konto für die 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 Anwendung sollte überprüfen, ob die Statuswerte in der Anforderung und in der Antwort identisch sind. |
Fehlerantwort
Fehlerantworten können auch an den redirect_uri
gesendet werden, damit die App diese angemessen behandeln kann: Im Fall von prompt=none
wird folgender Fehler erwartet:
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 Gewährung 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. Zum Aktualisieren beider Tokentypen können Sie die oben erwähnte verborgene IFrame-Anforderung unter Verwendung des Parameters prompt=none
ausführen, um das Verhalten der Microsoft Identity Platform 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 |
required | 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. |
Nächste Schritte
- Wechseln Sie zu den MSAL JS-Beispielen, um in die Programmierung einzusteigen.
- Informieren Sie sich über den Autorisierungscodeflow als neuere und bessere Alternative zur impliziten Genehmigung.