Microsoft Identity Platform und der OAuth 2.0-Autorisierungscodeflow
Die Gewährung eines OAuth 2.0-Autorisierungscodes bzw. der Autorisierungscodeflow ermöglicht es einer Clientanwendung, autorisierten Zugriff auf geschützte Ressourcen wie beispielsweise Web-APIs zu erhalten. Der Autorisierungscodeflow erfordert einen Benutzer-Agent, der die Umleitung vom Autorisierungsserver (Microsoft Identity Platform) zurück zu Ihrer Anwendung unterstützt. Dies kann beispielsweise ein Webbrowser, ein Desktop oder eine mobile Anwendung sein, mit der sich ein Benutzer bei Ihrer Anwendung anmelden und auf seine Daten zugreifen kann.
In diesem Artikel werden Low-Level-Protokolldetails beschrieben, die nur bei der manuellen Erstellung und Ausgabe von unformatierten HTTP-Anforderungen zur Flowausführung benötigt werden, was wir nicht empfehlen. Verwenden Sie stattdessen eine von Microsoft erstellte und unterstützte Authentifizierungsbibliothek, um Sicherheitstoken abzurufen und geschützte Web-APIs in Ihren Apps aufzurufen.
Anwendungen mit Unterstützung des Autorisierungscodeflows
Verwenden Sie den Authentifizierungscodeflow in Verbindung mit Proof Key for Code Exchange (PKCE) und OpenID Connect (OIDC), um Zugriffstoken und ID-Token in den folgenden App-Typen abzurufen:
Protokolldetails
Der OAuth 2.0-Autorisierungscodefluss wird in Abschnitt 4.1 der OAuth 2.0-Spezifikationbeschrieben. Apps, die den OAuth 2.0-Autorisierungscodeflow verwenden, rufen ein access_token ab. Dieses wird anschließend in Anforderungen an Ressourcen eingefügt, die durch Microsoft Identity Platform geschützt sind ( typischerweise APIs). Apps können auch neue ID- und Zugriffstoken für zuvor authentifizierte Entitäten anfordern, indem sie einen Aktualisierungsmechanismus verwenden.
Diese Abbildung zeigt eine allgemeine Übersicht über den Authentifizierungsfluss:
Umleitungs-URIs für Single-Page-Webanwendungen (SPAs)
Umleitungs-URIs für SPAs, die den Authentifizierungscodeflow verwenden, erfordern eine spezielle Konfiguration.
- Fügen Sie einen Umleitungs-URI hinzu, der den Authentifizierungscodeflow mit PKCE und CORS (Cross-Origin Resource Sharing) unterstützt: Führen Sie die Schritte unter Umleitungs-URI: MSAL.js 2.0 mit dem Authentifizierungscodeflow aus.
- Aktualisieren eines Umleitungs-URIs: Legen Sie mithilfe des Anwendungsmanifest-Editors im Microsoft Entra Admin Center den
typedes URIs aufspafest.
Der Umleitungstyp spa ist abwärtskompatibel mit dem impliziten Flow. Apps, die derzeit den impliziten Flow zum Abrufen von Token verwenden, können ohne Probleme auf den Umleitungs-URI-Typ spa umgestellt werden und den impliziten Flow weiterhin verwenden. Trotz dieser Abwärtskompatibilität wird empfohlen, den Authentifizierungscodefluss mit PKCE für SPAs zu verwenden.
Wenn Sie versuchen, den Autorisierungscodeflow zu verwenden, ohne CORS für Ihren Umleitungs-URI einzurichten, wird folgender Fehler in der Konsole angezeigt:
access to XMLHttpRequest at 'https://login.microsoftonline.com/common/v2.0/oauth2/token' from origin 'yourApp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Wenn dies der Fall ist, rufen Sie Ihre App-Registrierung auf, und ändern Sie den Umleitungs-URI für Ihre App in den Typ spa.
Anwendung können keinen spa-Umleitungs-URI mit Nicht-SPA-Flows verwenden, zum Beispiel native Anwendungen oder Flows für Clientanmeldeinformationen. Zur Gewährleistung von Sicherheit und bewährten Methoden gibt Microsoft Identity Platform einen Fehler zurück, wenn Sie versuchen, einen spa-Umleitungs-URI ohne Origin-Header zu verwenden. Auf ähnliche Weise verhindert Microsoft Identity Platform auch bei Vorhandensein eines Origin-Headers die Verwendung von Clientanmeldeinformationen in allen Flows, um sicherzustellen, dass Geheimnisse aus dem Browser nicht verwendet werden.
Anfordern eines Autorisierungscodes
Der Autorisierungscodefluss beginnt damit, dass der Client den Benutzer auf den /authorize -Endpunkt leitet. In dieser Beispielanforderung fordert der Client die Berechtigungen openid, offline_access und https://graph.microsoft.com/mail.read vom Benutzer an.
Einige Berechtigungen sind auf Administratoren beschränkt, z. B. das Schreiben von Daten in das Verzeichnis einer Organisation mithilfe von Directory.ReadWrite.All. Wenn Ihre Anwendung von einem Organisationsbenutzer Zugriff auf eine dieser Berechtigungen anfordert, wird dem Benutzer in einer Fehlermeldung mitgeteilt, dass er nicht befugt ist, den Berechtigungen Ihrer App zuzustimmen. Zugriff auf Bereiche, die auf Administratoren beschränkt sind, sollten Sie direkt von einem globalen Administrator anfordern. Weitere Informationen finden Sie unter Auf Administratoren beschränkte Berechtigungen.
Sofern nicht anders angegeben, gibt es keine Standardwerte für optionale Parameter. Es gibt jedoch ein Standardverhalten für eine Anforderung, bei dem optionale Parameter ausgelassen werden. Das Standardverhalten besteht im Anmelden des einzigen aktuellen Benutzers, im Anzeigen der Kontoauswahl bei mehreren Benutzern oder im Anzeigen der Anmeldeseite, wenn keine Benutzer angemeldet sind.
// Line breaks for legibility only
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
| Parameter | Erforderlich/optional | Beschreibung |
|---|---|---|
tenant |
required | Mit dem {tenant} -Wert im Pfad der Anforderung kann festgelegt werden, welche Benutzer sich bei der Anwendung anmelden können. Gültige Werte sind common, organizations, consumers und Mandantenbezeichner. In Gastszenarien, in denen Sie einen Benutzer von einem Mandanten bei einem anderen Mandanten anmelden, müssen Sie die Mandanten-ID angeben, um ihn beim Ressourcenmandanten anmelden zu können. Weitere Informationen finden Sie unter Endpunkte. |
client_id |
Erforderlich | Die Anwendungs-ID (Client-ID), die Ihrer App auf der Benutzeroberfläche „App-Registrierungen“ im Microsoft Entra Admin Center zugewiesen ist. |
response_type |
Erforderlich | Muss code für den Autorisierungscodefluss enthalten. Kann auch id_token oder token enthalten, wenn der Hybridflow verwendet wird. |
redirect_uri |
Erforderlich | Der redirect_uri deiner App, wohin Authentifizierungsantworten gesendet und von deiner App empfangen werden können. 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. Für native und mobile Anwendungen sollten Sie einen der empfohlenen Werte verwenden: https://login.microsoftonline.com/common/oauth2/nativeclient für Anwendungen mit eingebetteten Browsern oder http://localhost für Anwendungen, die Systembrowser verwenden. |
scope |
erforderlich | Eine durch Leerzeichen getrennte Liste mit Bereichen , denen der Benutzer zustimmen soll. Für den /authorize-Abschnitt der Anforderung kann dieser Parameter mehrere Ressourcen abdecken. Mit diesem Wert kann Ihre App die Zustimmung für mehrere Web-APIs erhalten, die Sie aufrufen möchten. |
response_mode |
empfohlen | Gibt an, wie die Identitätsplattform das angeforderte Token an Ihre App zurückgeben soll. Unterstützte Werte: - query: Standard beim Anfordern eines Zugriffstokens. Gibt den Code als Abfragezeichenfolgenparameter im Umleitungs-URI an. Der query-Parameter wird beim Anfordern eines ID-Tokens über den impliziten Flow nicht unterstützt. - fragment: Standard beim Anfordern eines ID-Tokens mithilfe des impliziten Flusses. Wird auch unterstützt, wenn ausschließlich ein Code angefordert wird.- form_post: Führt ein POST-Element mit dem Code für Ihren Umleitungs-URI aus. Wird beim Anfordern eines Codes unterstützt. |
state |
empfohlen | Ein in der Anforderung enthaltener Wert, der ebenfalls in der Tokenantwort 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 Wert kann außerdem Informationen zum Status des Benutzers in der App codieren, bevor die Authentifizierungsanforderung erfolgte. Beispielsweise kann er die Seite oder Ansicht codieren, auf der sie sich befunden haben. |
prompt |
optional | Gibt den Typ der erforderlichen Benutzerinteraktion an. Gültige Werte sind login, none, consent und select_account.- prompt=login zwingt den Benutzer, die Anmeldeinformationen bei dieser Anforderung einzugeben. Einmaliges Anmelden ist dadurch nicht möglich.- prompt=none ist das Gegenteil. Dieser Wert stellt sicher, dass dem Benutzer keine interaktive Eingabeaufforderung angezeigt wird. Wenn die Anforderung nicht über einmaliges Anmelden im Hintergrund abgeschlossen werden kann, gibt Microsoft Identity Platform den Fehler interaction_required zurück.- 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.- prompt=select_account unterbricht beim einmaligen Anmelden die Kontoauswahlumgebung, in der entweder alle Konten in der Sitzung, alle gespeicherten Konten oder eine Option zur Verwendung eines ganz anderen Kontos aufgelistet werden. |
login_hint |
optional | Sie können diesen Parameter verwenden, um das Feld für Benutzernamen und E-Mail-Adresse auf der Anmeldeseite vorab für den Benutzer auszufüllen. Anwendungen können diesen Parameter bei der erneuten Authentifizierung verwenden, nachdem bereits der login_hint optionale Anspruch aus einer früheren Anmeldung extrahiert wurde. |
domain_hint |
optional | Wenn dieser Parameter vorhanden ist, überspringt die App den E-Mail-basierten Ermittlungsvorgang, den der Benutzer auf der Anmeldeseite durchläuft, was die Benutzerfreundlichkeit etwas verbessert. Dazu zählt beispielsweise auch das Senden der Informationen an den Verbundidentitätsanbieter. Apps können diesen Parameter durch Extrahieren von tid aus einer früheren Anmeldung für die erneute Authentifizierung verwenden. |
code_challenge |
Empfohlen/erforderlich | Wird verwendet, um die Gewährung von Autorisierungscodes über Proof Key for Code Exchange (PKCE) zu sichern. Erforderlich, wenn code_challenge_method enthalten ist. Weitere Informationen finden Sie unter PKCE RFC. Dieser Parameter wird jetzt für alle Anwendungstypen (sowohl für öffentliche als auch für vertrauliche Clients) empfohlen und ist in Microsoft Identity Platform für Single-Page-Webapps, die den Autorisierungscodeflow verwenden erforderlich. |
code_challenge_method |
Empfohlen/erforderlich | Die Methode wird zum Codieren von code_verifier für den code_challenge-Parameter verwendet. Dieser SOLLTE zwar S256 lauten, doch die Spezifikation ermöglicht auch die Verwendung von plain, wenn der Client SHA256 nicht unterstützen kann. Wenn ausgeschlossen, wird angenommen, dass code_challenge Klartext ist, wenn code_challenge enthalten ist. Microsoft Identity Platform unterstützt sowohl plain als auch S256. Weitere Informationen finden Sie unter PKCE RFC. Dieser Parameter ist für Single-Page-Webanwendungen, die den Autorisierungscodeflow verwenden erforderlich. |
An dieser Stelle wird der Benutzer aufgefordert, seine Anmeldeinformationen einzugeben und die Authentifizierung abzuschließen. Microsoft Identity Platform stellt auch sicher, dass der Benutzer den Berechtigungen zugestimmt hat, die im Abfrageparameter scope angegeben sind. Wenn der Benutzer keiner Berechtigung zugestimmt hat, wird er aufgefordert, den erforderlichen Berechtigungen zuzustimmen. Weitere Informationen finden Sie unter Berechtigungen und Zustimmung in Microsoft Identity Platform.
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
Dieses Beispiel zeigt eine erfolgreiche Antwort mithilfe von response_mode=query:
GET http://localhost?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345
| Parameter | Beschreibung |
|---|---|
code |
Der von der App angeforderte authorization_code. Die App kann mithilfe des Autorisierungscodes ein Zugriffstoken für die Zielressource anfordern. Autorisierungscodes sind von kurzer Lebensdauer. In der Regel laufen sie nach etwa 10 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 Statuswerte in der Anforderung und in der Antwort identisch sind. |
Sie können auch ein ID-Token erhalten, wenn Sie eines anfordern und die implizite Genehmigung in Ihrer Anwendungsregistrierung aktiviert ist. Dieses Verhalten wird manchmal als Hybridflow bezeichnet. Er wird von Frameworks wie ASP.NET verwendet.
Fehlerantwort
Fehlerantworten können auch an den redirect_uri gesendet werden, damit die App diese angemessen behandeln kann:
GET http://localhost?
error=access_denied
&error_description=the+user+canceled+the+authentication
| Parameter | Beschreibung |
|---|---|
error |
Eine Fehlercodezeichenfolge, die zum Klassifizieren der Fehlertypen und für die Reaktion auf Fehler verwendet werden kann. Dieser Teil des Fehlers wird bereitgestellt, damit die App angemessen auf den Fehler reagieren kann, erklärt aber nicht ausführlich, warum der Fehler aufgetreten ist. |
error_description |
Eine spezielle Fehlermeldung, mit der Entwickler die Ursache eines Authentifizierungsfehlers identifizieren können. Dieser Teil des Fehlers enthält die meisten nützlichen Informationen zur Ursache des Fehlers. |
Fehlercodes beim Autorisierungsendpunktfehler
Die folgende Tabelle beschreibt die verschiedenen Fehlercodes, die im error -Parameter der Fehlerantwort zurückgegeben werden können:
| Fehlercode | Beschreibung | Clientaktion |
|---|---|---|
invalid_request |
Protokollfehler, z.B. ein fehlender erforderlicher Parameter. | Korrigieren Sie die Anforderung, und senden Sie sie erneut. Dies ist ein Entwicklungsfehler, der in der Regel bei ersten Tests entdeckt wird. |
unauthorized_client |
Die Clientanwendung darf keinen Autorisierungscode anfordern. | Dieser Fehler tritt in der Regel auf, wenn die Clientanwendung nicht in Microsoft Entra ID registriert ist oder dem Microsoft Entra-Mandanten des Benutzers nicht hinzugefügt wurde. Die Anwendung kann den Benutzer zum Installieren der Anwendung und zum Hinzufügen zu Microsoft Entra ID auffordern. |
access_denied |
Der Ressourcenbesitzer hat die Zustimmung verweigert. | Die Clientanwendung kann den Benutzer benachrichtigen, dass sie ohne Zustimmung des Benutzers nicht fortfahren kann. |
unsupported_response_type |
Der Autorisierungsserver unterstützt den Antworttyp in der Anforderung nicht. | Korrigieren Sie die Anforderung, und senden Sie sie erneut. Dies ist ein Entwicklungsfehler, der in der Regel bei ersten Tests entdeckt wird. In einem Hybridflow weist dieser Fehler darauf hin, dass Sie in der Client-App-Registrierung die Einstellung für die implizite Genehmigung des ID-Tokens aktivieren müssen. |
server_error |
Der Server hat einen unerwarteten Fehler erkannt. | Wiederholen Sie die Anforderung. Diese Fehler werden durch temporäre Bedingungen verursacht. Die Client-Anwendung könnte dem Benutzer erklären, dass ihre Antwort aufgrund eines vorübergehenden Fehlers verzögert ist. |
temporarily_unavailable |
Der Server ist vorübergehend überlastet und kann die Anforderung nicht verarbeiten. | Wiederholen Sie die Anforderung. Die Clientanwendung kann dem Benutzer erklären, dass ihre Antwort aufgrund einer temporären Bedingung verzögert ist. |
invalid_resource |
Die Zielressource ist ungültig, da sie entweder nicht vorhanden ist, von Microsoft Entra ID nicht gefunden werden kann oder nicht ordnungsgemäß konfiguriert ist. | Dieser Fehler gibt an, dass die Ressource (falls vorhanden) im Mandanten nicht konfiguriert wurde. Die Anwendung kann den Benutzer zum Installieren der Anwendung und zum Hinzufügen zu Microsoft Entra ID auffordern. |
login_required |
Zu viele oder keine Benutzer gefunden. | Der Client hat die Authentifizierung im Hintergrund angefordert (prompt=none), ein einzelner Benutzer konnte jedoch nicht gefunden werden. Dieser Fehler kann bedeuten, dass in der Sitzung mehrere Benutzer oder keine Benutzer aktiv sind. Bei diesem Fehler wird der ausgewählte Mandant berücksichtigt. Wenn beispielsweise zwei Microsoft Entra-Konten und ein Microsoft-Konto aktiv sind und consumers ausgewählt wird, funktioniert die automatische Authentifizierung. |
interaction_required |
Die Anforderung erfordert eine Benutzerinteraktion. | Es ist ein weiterer Authentifizierungsschritt oder eine Zustimmung erforderlich. Wiederholen Sie die Anforderung ohne prompt=none. |
Anfordern eines ID-Tokens und Hybridflow
Um vor dem Einlösen eines Autorisierungscodes zu ermitteln, wer der Benutzer ist, fordern Anwendungen häufig auch ein ID-Token an, wenn sie den Autorisierungscode anfordern. Dieser Ansatz wird als Hybridflow bezeichnet, da dabei OIDC mit dem OAuth2-Autorisierungscodeflow kombiniert wird.
Der Hybridflow wird häufig bei Web-Apps verwendet, um eine Seite für einen Benutzer zu rendern, ohne bei der Codeeinlösung eine Sperrung zu verursachen. Dies gilt besonders für ASP.NET. Sowohl einseitige als auch herkömmliche Web-Apps profitieren von der geringeren Latenz dieses Modells.
Der Hybridflow ist bis auf drei Ergänzungen identisch mit dem zuvor beschriebenen Autorisierungscodeflow. All diese Ergänzungen sind erforderlich, um ein ID-Token anzufordern: neue Bereiche, ein neuer Antworttyp (response_type) und ein neuer Abfrageparameter nonce.
// Line breaks for legibility only
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code%20id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=fragment
&scope=openid%20offline_access%20https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
&state=12345
&nonce=abcde
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
| Aktualisierte Parameter | Erforderlich/optional | Beschreibung |
|---|---|---|
response_type |
erforderlich | Das Hinzufügen von id_token informiert den Server darüber, dass die Anwendung in der Antwort vom /authorize-Endpunkt ein ID-Token erwartet. |
scope |
Erforderlich | Bei ID-Token muss dieser Parameter so geändert werden, dass er die ID-Tokenbereiche openid und optional profile und email enthält. |
nonce |
erforderlich | Ein Wert in der von der App erzeugten Anforderung, die im resultierenden id_token-Element 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. |
response_mode |
empfohlen | Gibt die Methode an, die zum Senden des resultierenden Tokens zurück an Ihre App verwendet werden soll. Der Standardwert lautet query nur für einen Autorisierungscode, jedoch lautet er fragment, wenn die Anforderung einen id_token response_type wie in der OpenID-Spezifikation angegeben ist. Wir empfehlen form_post für Apps, besonders wenn http://localhost als Umleitungs-URI verwendet wird. |
Die Verwendung von fragment als Antwortmodus verursacht Probleme bei Web-Apps, die den Code aus der Umleitung lesen. Browser übergeben das Fragment nicht an den Webserver. In diesen Fällen sollten die Apps den Antwortmodus form_post verwenden, mit dem sichergestellt wird, dass alle Daten an den Server gesendet werden.
Erfolgreiche Antwort
Dieses Beispiel zeigt eine erfolgreiche Antwort mithilfe von response_mode=fragment:
GET https://login.microsoftonline.com/common/oauth2/nativeclient#
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&id_token=eYj...
&state=12345
| Parameter | BESCHREIBUNG |
|---|---|
code |
Der Autorisierungscode, den die App angefordert hat. Die App kann den Autorisierungscode zum Anfordern eines Zugriffstokens für die Zielressource verwenden. Autorisierungscodes sind kurzlebig und laufen in der Regel nach etwa zehn Minuten ab. |
id_token |
Ein ID-Token für den Benutzer, ausgestellt über die implizite Genehmigung. Es enthält einen speziellen c_hash-Anspruch: den Hash des code in derselben Anforderung. |
state |
Wenn ein Parameter state 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. |
Einlösen eines Codes für ein Zugriffstoken
Bei allen vertraulichen Clients haben Sie die Wahl zwischen geheimen Clientschlüsseln oder Zertifikatanmeldeinformationen. Symmetrische gemeinsame Geheimnisse werden von Microsoft Identity Platform generiert. Zertifikatanmeldeinformationen sind asymmetrische Schlüssel, die vom Entwickler hochgeladen werden. Weitere Informationen finden Sie unter Microsoft Identity Platform-Zertifikatanmeldeinformationen für die Anwendungsauthentifizierung.
Für optimale Sicherheit wird die Verwendung von Zertifikatanmeldeinformationen empfohlen. Öffentliche Clients, die native Anwendungen und Single-Page-Webapps enthalten, dürfen beim Einlösen eines Autorisierungscodes keine Geheimnisse oder Zertifikate verwenden. Stellen Sie immer sicher, dass Ihre Umleitungs-URIs den Typ der Anwendung enthalten und eindeutig sind.
Anfordern eines Zugriffstokens mit „client_secret“
Nun, da Sie einen authorization_code erworben und die Berechtigung vom Benutzer erhalten haben, können Sie den code für ein access_token für die gewünschte Ressource einlösen. Senden Sie zum Einlösen des code eine POST-Anforderung an den /token-Endpunkt:
// Line breaks for legibility only
POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=11112222-bbbb-3333-cccc-4444dddd5555
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
&client_secret=sampleCredentia1s // NOTE: Only required for web apps. This secret needs to be URL-Encoded.
| Parameter | Erforderlich/optional | Beschreibung |
|---|---|---|
tenant |
required | Mit dem {tenant} -Wert im Pfad der Anforderung kann festgelegt werden, welche Benutzer sich bei der Anwendung anmelden können. Gültige Werte sind common, organizations, consumers und Mandantenbezeichner. Weitere Informationen finden Sie unter Endpunkte. |
client_id |
Erforderlich | Die Anwendungs-ID (Client-ID), die Ihrer App auf der Seite „App-Registrierungen“ im Microsoft Entra Admin Center zugewiesen ist. |
scope |
optional | Eine durch Leerzeichen getrennte Liste von Bereichen. Die Bereiche müssen alle von einer einzelnen Ressource stammen, zusammen mit den OIDC-Bereichen (profile, openid, email). Weitere Informationen finden Sie unter Berechtigungen und Zustimmung in Microsoft Identity Platform. Dieser Parameter ist eine Microsoft-Erweiterung für den Autorisierungscodeflow, der es Apps ermöglichen soll, bei der Tokeneinlösung die Ressource zu deklarieren, für die das Token bestimmt ist. |
code |
Erforderlich | Der authorization_code, den du im ersten Abschnitt des Flows abgerufen hast. |
redirect_uri |
Erforderlich | Derselbe redirect_uri-Wert, der zum Abrufen des authorization_code verwendet wurde. |
grant_type |
erforderlich | Muss der authorization_code für den Autorisierungscodefluss sein. |
code_verifier |
empfohlen | Derselbe code_verifier, der zum Erhalten des authorisation_code verwendet wurde. Erforderlich, wenn PKCE bei der Anforderung für die Gewährung des Autorisierungscodes verwendet wurde. Weitere Informationen finden Sie unter PKCE RFC. |
client_secret |
Für vertrauliche Web-Apps erforderlich | Der geheime App-Schlüssel, den Sie im App-Registrierungsportal für Ihre App erstellt haben. Sie sollten das Anwendungsgeheimnis nicht in einer nativen App oder in einer Single-Page-Webapp verwenden, das ein client_secret nicht zuverlässig auf Geräten oder Webseiten gespeichert werden kann. Es ist für Web-Apps und Web-APIs erforderlich, die das client_secret sicher auf dem Server speichern können. Wie alle hier genannten Parameter muss der geheime Clientschlüssel vor dem Senden URL-codiert sein. Dieser Schritt wird mit dem SDK ausgeführt. Weitere Informationen zur URI-Kodierung finden Sie in der Spezifikation URI Generic Syntax. Das Standardauthentifizierungsmuster der Bereitstellung von Anmeldeinformationen im Autorisierungsheader gemäß RFC 6749 wird ebenfalls unterstützt. |
Anfordern eines Zugriffstokens mit Zertifikatanmeldeinformationen
// Line breaks for legibility only
POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
| Parameter | Erforderlich/optional | Beschreibung |
|---|---|---|
tenant |
required | Mit dem {tenant} -Wert im Pfad der Anforderung kann festgelegt werden, welche Benutzer sich bei der Anwendung anmelden können. Gültige Werte sind common, organizations, consumers und Mandantenbezeichner. Weitere Informationen finden Sie unter Endpunkte. |
client_id |
Erforderlich | Die Anwendungs-ID (Client-ID), die Ihrer App auf der Seite „App-Registrierungen“ im Microsoft Entra Admin Center zugewiesen ist. |
scope |
optional | Eine durch Leerzeichen getrennte Liste von Bereichen. Die Bereiche müssen alle von einer einzelnen Ressource stammen, zusammen mit den OIDC-Bereichen (profile, openid, email). Weitere Informationen finden Sie unter Berechtigungen, Zustimmung und Bereiche. Dieser Parameter ist eine Microsoft-Erweiterung für den Autorisierungscodeflow. Mit dieser Erweiterung können Apps bei der Tokeneinlösung die Ressource deklarieren, für die sie das Token verwenden möchten. |
code |
Erforderlich | Der authorization_code, den du im ersten Abschnitt des Flows abgerufen hast. |
redirect_uri |
Erforderlich | Derselbe redirect_uri-Wert, der zum Abrufen des authorization_code verwendet wurde. |
grant_type |
erforderlich | Muss der authorization_code für den Autorisierungscodefluss sein. |
code_verifier |
empfohlen | Derselbe code_verifier, der zum Abrufen des authorization_code verwendet wurde. Erforderlich, wenn PKCE bei der Anforderung für die Gewährung des Autorisierungscodes verwendet wurde. Weitere Informationen finden Sie unter PKCE RFC. |
client_assertion_type |
Für vertrauliche Web-Apps erforderlich | Der Wert muss auf festgelegt urn:ietf:params:oauth:client-assertion-type:jwt-bearer werden, um Zertifikatanmeldeinformationen verwenden zu können. |
client_assertion |
Für vertrauliche Web-Apps erforderlich | Eine Assertion (JSON-Webtoken, JWT), die Sie benötigen, um das Zertifikat, das Sie als Anmeldeinformationen für Ihre Anwendung registriert haben, zu erstellen und sich damit anzumelden. Informationen zum Registrieren Ihres Zertifikats sowie zum Format der Assertion finden Sie im Abschnitt Zertifikatanmeldeinformationen. |
Die Parameter sind nahezu identisch mit den Parametern der Anforderung mit dem gemeinsamen Geheimnis, nur werden anstelle des Parameters client_secret die beiden Parameter client_assertion_type und client_assertion verwendet.
Erfolgreiche Antwort
Das Beispiel enthält eine erfolgreiche Tokenantwort:
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"token_type": "Bearer",
"expires_in": 3599,
"scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
"refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
| Parameter | Beschreibung |
|---|---|
access_token |
Das angeforderte Zugriffstoken. Die App kann dieses Token für die Authentifizierung mit der gesicherten Ressource (z. B. einer Web-API) verwenden. |
token_type |
Gibt den Wert des Tokentyps an. Der einzige Typ, der von Microsoft Entra ID unterstützt wird, ist Bearer. |
expires_in |
Gibt an, wie lange das Zugriffstoken (in Sekunden) gültig ist. |
scope |
Die Bereiche, für die das access_token gültig ist. Optional. Dieser Parameter ist kein Standardparameter. Wenn er nicht angegeben wird, gilt das Token für die Bereiche, die im ersten Abschnitt des Flows angefordert wurden. |
refresh_token |
Ein Aktualisierungstoken von OAuth 2.0. Die App kann dieses Token verwenden, um nach Ablauf der aktuellen Zugriffstoken zusätzliche Zugriffstoken zu erhalten. Aktualisierungstoken sind langlebig. Sie können den Zugriff auf Ressourcen über einen längeren Zeitraum beibehalten. Weitere Informationen zum Aktualisieren eines Zugriffstokens finden Sie weiter unten in diesem Artikel unter Aktualisieren des Zugriffstokens. Hinweis: Wird nur bei Anforderung des offline_access-Bereichs bereitgestellt. |
id_token |
JSON Web Token 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, und vertrauliche Clients können dieses Token zur Autorisierung verwenden. Weitere Informationen zu ID-Token finden Sie unter id_token reference. Hinweis: Wird nur bei Anforderung des openid-Bereichs bereitgestellt. |
Fehlerantwort
Dieses Beispiel ist eine Fehlerantwort:
{
"error": "invalid_scope",
"error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/mail.read is not valid.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2016-01-09 02:02:12Z",
"error_codes": [
70011
],
"timestamp": "2016-01-09 02:02:12Z",
"trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333",
"correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
}
| Parameter | Beschreibung |
|---|---|
error |
Eine Fehlercodezeichenfolge, die zum Klassifizieren der Fehlertypen und für die Reaktion auf Fehler verwendet werden kann. |
error_description |
Eine spezielle Fehlermeldung, mit der Entwickler die Ursache eines Authentifizierungsfehlers identifizieren können. |
error_codes |
Eine Liste der STS-spezifischen Fehlercodes, die bei der Diagnose helfen können. |
timestamp |
Der Zeitpunkt, zu dem der Fehler aufgetreten ist |
trace_id |
Ein eindeutiger Bezeichner für die Anforderung, die bei der Diagnose helfen kann |
correlation_id |
Ein eindeutiger Bezeichner für die Anforderung, die bei der komponentenübergreifenden Diagnose helfen kann |
Fehlercodes für Token-Endpunktfehler
| Fehlercode | Beschreibung | Clientaktion |
|---|---|---|
invalid_request |
Protokollfehler, z.B. ein fehlender erforderlicher Parameter. | Korrigieren Sie die Anforderung oder die App-Registrierung, und senden Sie die Anforderung erneut. |
invalid_grant |
Der Autorisierungscode oder PKCE-Codeprüfer ist ungültig oder abgelaufen. | Versuchen Sie, eine neue Anforderung für den /authorize-Endpunkt zu senden, und stellen Sie sicher, dass der Parameter code_verifier korrekt ist. |
unauthorized_client |
Der authentifizierte Client ist zur Verwendung dieses Autorisierungsgewährungstyps nicht autorisiert. | Dieser Fehler tritt in der Regel auf, wenn die Clientanwendung nicht in Microsoft Entra ID registriert ist oder dem Microsoft Entra-Mandanten des Benutzers nicht hinzugefügt wurde. Die Anwendung kann den Benutzer zum Installieren der Anwendung und zum Hinzufügen zu Microsoft Entra ID auffordern. |
invalid_client |
Clientauthentifizierung fehlgeschlagen. | Die Client-Anmeldeinformationen sind nicht gültig. Um das Problem zu beheben, aktualisiert die Fachkraft in der IT-Verwaltung für Anwendungen die Anmeldeinformationen. |
unsupported_grant_type |
Der Autorisierungsserver unterstützt den Autorisierungsgewährungstyp nicht. | Ändern Sie den Gewährungstyp in der Anforderung. Diese Art von Fehler sollte nur während der Entwicklung auftreten und bei den ersten Tests erkannt werden. |
invalid_resource |
Die Zielressource ist ungültig, da sie entweder nicht vorhanden ist, von Microsoft Entra ID nicht gefunden werden kann oder nicht ordnungsgemäß konfiguriert ist. | Dieser Code gibt an, dass die Ressource (falls vorhanden) im Mandanten nicht konfiguriert wurde. Die Anwendung kann den Benutzer zum Installieren der Anwendung und zum Hinzufügen zu Microsoft Entra ID auffordern. |
interaction_required |
Dies ist kein Standardverhalten, da die OIDC-Spezifikation diesen Code nur im /authorize-Endpunkt erfordert. Die Anforderung erfordert eine Benutzerinteraktion. Beispielsweise ist ein zusätzlicher Schritt zur Authentifizierung erforderlich. |
Wiederholen Sie die /authorize-Anforderung mit den gleichen Bereichen. |
temporarily_unavailable |
Der Server ist vorübergehend überlastet und kann die Anforderung nicht verarbeiten. | Wiederholen Sie die Anforderung nach kurzer Zeit. Die Clientanwendung kann dem Benutzer erklären, dass ihre Antwort aufgrund einer temporären Bedingung verzögert ist. |
consent_required |
Die Anforderung erfordert die Zustimmung des Benutzers. Dieser Fehler ist kein Standardfehler. Er wird in der Regel nur für den /authorize-Endpunkt nach OIDC-Spezifikationen zurückgegeben. Wird zurückgegeben, wenn im Codeeinlösungsflow der Parameter scope verwendet wurde, für dessen Anforderung die Client-App keine Berechtigung besitzt. |
Der Client muss den Benutzer mit dem richtigen Bereich wieder an den /authorize-Endpunkt zurückverweisen, damit die Zustimmung ausgelöst wird. |
invalid_scope |
Der von der App angeforderte Bereich ist ungültig. | Aktualisieren Sie den Wert des Parameters scope in der Authentifizierungsanforderung auf einen gültigen Wert. |
Hinweis
Single-Page-Webanwendungen erhalten möglicherweise eine Fehlermeldung des Typs invalid_request, die besagt, dass eine ursprungsübergreifende Tokeneinlösung nur für den Clienttyp „Single-Page-Webanwendung“ zulässig ist. Dies weist darauf hin, dass der zum Anfordern des Tokens verwendete Umleitungs-URI nicht als spa-Umleitungs-URI gekennzeichnet wurde. Informationen zum Aktivieren dieses Flows finden Sie im Abschnitt Für Single-Page-Webanwendungen erforderliche Einrichtung.
Verwenden des Zugriffstokens
Nachdem Sie nun erfolgreich ein access_token abgerufen haben, können Sie das Token für Anforderungen an Web-APIs verwenden, indem Sie es in den Authorization-Header einschließen:
GET /v1.0/me/messages
Host: https://graph.microsoft.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
Aktualisieren des Zugriffstokens
Zugriffs- und ID-Token sind kurzlebig. Aktualisieren Sie sie, nachdem sie abgelaufen sind, um weiterhin auf Ressourcen zugreifen zu können. Dazu übermitteln Sie eine weitere POST-Anforderung an den /token-Endpunkt. Geben Sie den refresh_token anstelle von code an. Aktualisierungstoken sind für alle Berechtigungen gültig, für die Ihr Client bereits Zustimmung erhalten hat. Beispielsweise kann ein Aktualisierungstoken, das für eine scope=mail.read-Anforderung ausgegeben wird, verwendet werden, um ein neues Zugriffstoken für scope=api://contoso.com/api/UseResource anzufordern.
Für Aktualisierungstoken für Web-Apps und native Apps ist keine bestimmte Lebensdauer festgelegt. Normalerweise verfügen Aktualisierungstoken über relativ lange Lebensdauern. In einigen Fällen laufen Aktualisierungstoken jedoch ab, werden widerrufen oder verfügen nicht über ausreichende Berechtigungen für die gewünschte Aktion. Ihre Anwendung muss Fehler, die vom Tokenausstellungsendpunkt zurückgegeben werden erwarten und behandeln. Single-Page-Webapps erhalten ein Token mit einer Lebensdauer von 24 Stunden, d. h. es ist täglich eine neue Authentifizierung erforderlich. Diese Aktion kann im Hintergrund in einem iFrame durchgeführt werden, wenn Cookies von Drittanbietern aktiviert sind. Dies muss in Browsern ohne Drittanbietercookies (z. B. Safari) in einem Frame der obersten Ebene (entweder vollständige Seitennavigation oder Popupfenster) erfolgen.
Aktualisierungstoken werden nicht widerrufen, wenn sie zum Erhalten neuer Zugriffstoken verwendet werden. Es wird erwartet, dass Sie das alte Aktualisierungstoken verwerfen. Die OAuth 2.0-Spezifikation besagt Folgendes: „Der Autorisierungsserver KANN ein neues Aktualisierungstoken ausstellen. In dem Fall MUSS der Client das alte Aktualisierungstoken verwerfen und durch das neue Aktualisierungstoken ersetzen. Der Autorisierungsserver KANN das alte Aktualisierungstoken nach dem Ausstellen eines neuen Aktualisierungstokens für den Client widerrufen.“
Wichtig
Aktualisierungstoken, die an einen als spa registrierten Umleitungs-URI gesendet werden, laufen nach 24 Stunden ab. Weitere Aktualisierungstoken, die mithilfe des ersten Aktualisierungstokens abgerufen werden, übernehmen diese Gültigkeitsdauer, sodass Apps darauf vorbereitet sein müssen, den Autorisierungscodeflow mithilfe einer interaktiven Authentifizierung erneut auszuführen, um alle 24 Stunden ein neues Aktualisierungstoken abzurufen. Benutzer müssen ihre Anmeldeinformationen nicht eingeben und sehen in der Regel keine Benutzeroberfläche, sondern nur ein erneutes Laden Ihrer Anwendung. Der Browser muss die Anmeldeseite in einem Frame der obersten Ebene aufrufen, um die Anmeldesitzung anzuzeigen. Dies liegt an den Datenschutzfunktionen bei Browsern, die Cookies von Drittanbietern blockieren.
// Line breaks for legibility only
POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=sampleCredentia1s // NOTE: Only required for web apps. This secret needs to be URL-Encoded
| 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. Gültige Werte sind common, organizations, consumers und Mandantenbezeichner. Weitere Informationen finden Sie unter Endpunkte. |
client_id |
Erforderlich | Die Anwendungs-ID (Client-ID), die Ihrer App auf der Benutzeroberfläche „App-Registrierungen“ im Microsoft Entra Admin Center zugewiesen ist. |
grant_type |
Erforderlich | Muss der refresh_token für diesen Abschnitt des Autorisierungscodeflusses sein. |
scope |
optional | Eine durch Leerzeichen getrennte Liste von Bereichen. Die in diesem Abschnitt angeforderten Bereiche müssen den Bereichen entsprechen oder eine Teilmenge der Bereiche sein, die im ersten Abschnitt der authorization_code-Anforderung angefordert wurden. Wenn die in dieser Anforderung angegebenen Bereiche mehrere Ressourcenserver umfassen, gibt Microsoft Identity Platform ein Token für die im ersten Bereich angegebene Ressource zurück. Weitere Informationen finden Sie unter Berechtigungen und Zustimmung in Microsoft Identity Platform. |
refresh_token |
Erforderlich | Das refresh_token, das Sie im zweiten Abschnitt des Flows erhalten haben. |
client_secret |
erforderlich für Web-Apps | Das Anwendungsgeheimnis, das du im App-Registrierungsportal für deine App erstellt hast. Es sollte nicht in nativen Apps verwendet werden, da client_secret nicht zuverlässig auf Geräten gespeichert werden können. Es ist für Web-Apps und Web-APIs erforderlich, die das client_secret sicher auf dem Server speichern können. Dieser geheime Schlüssel muss URL-codiert sein. Weitere Informationen finden Sie in der Spezifikation der generischen URI-Syntax. |
Erfolgreiche Antwort
Das Beispiel enthält eine erfolgreiche Tokenantwort:
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"token_type": "Bearer",
"expires_in": 3599,
"scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
"refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
| Parameter | Beschreibung |
|---|---|
access_token |
Das angeforderte Zugriffstoken. Die App kann dieses Token für die Authentifizierung mit der gesicherten Ressource (z. B. einer Web-API) verwenden. |
token_type |
Gibt den Wert des Tokentyps an. Der einzige Typ, der Microsoft Entra ID unterstützt, ist Bearer. |
expires_in |
Gibt an, wie lange das Zugriffstoken (in Sekunden) gültig ist. |
scope |
Die Bereiche, für die das access_token gültig ist. |
refresh_token |
Ein neues Aktualisierungstoken von OAuth 2.0. Ersetzen Sie das alte Aktualisierungstoken durch das neu erworbene Aktualisierungstoken, um sicherzustellen, dass Ihre Aktualisierungstoken so lange wie möglich gültig bleiben. Hinweis: Wird nur bei Anforderung des offline_access-Bereichs bereitgestellt. |
id_token |
Unsigniertes JSON-Webtoken (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 Microsoft Identity Platform – ID-Token. Hinweis: Wird nur bei Anforderung des openid-Bereichs bereitgestellt. |
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
{
"error": "invalid_scope",
"error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/mail.read is not valid.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2016-01-09 02:02:12Z",
"error_codes": [
70011
],
"timestamp": "2016-01-09 02:02:12Z",
"trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333",
"correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
}
| Parameter | Beschreibung |
|---|---|
error |
Eine Fehlercodezeichenfolge, die zum Klassifizieren der Fehlertypen und für die Reaktion auf Fehler verwendet werden kann. |
error_description |
Eine spezifische Fehlermeldung, mit der Entwickler die Hauptursache eines Authentifizierungsfehlers identifizieren können. |
error_codes |
Eine Liste der STS-spezifischen Fehlercodes, die bei der Diagnose helfen können. |
timestamp |
Der Zeitpunkt, zu dem der Fehler aufgetreten ist |
trace_id |
Ein eindeutiger Bezeichner für die Anforderung, die bei der Diagnose helfen kann |
correlation_id |
Ein eindeutiger Bezeichner für die Anforderung, die bei der komponentenübergreifenden Diagnose helfen kann |
Eine Beschreibung der Fehlercodes und der jeweils empfohlenen Clientaktion finden Sie unter Fehlercodes für Token-Endpunktfehler.
Nächste Schritte
- Wechseln Sie zu den MSAL JS-Beispielen, um in die Programmierung einzusteigen.
- Weitere Informationen finden Sie unter Szenarien für den Tokenaustausch.