Microsoft Identity Platform und der Fluss von OAuth 2.0-Clientanmeldeinformationen

Sie können die in RFC 6749 spezifizierte OAuth 2.0 Client Credentials Grant, manchmal auch zweistufiges OAuth genannt, für den Zugriff auf web-gehostete Ressourcen unter Verwendung der Identität einer Anwendung verwenden. Diese Art der Gewährung wird häufig für Interaktionen zwischen Servern verwendet, die ohne Benutzereingriff im Hintergrund ausgeführt werden müssen. Diese Anwendungstypen werden oft als Daemons oder Dienstkonten bezeichnet.

In diesem Artikel wird beschrieben, wie Sie direkt mit dem Protokoll in Ihrer Anwendung programmieren. 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. Nebenbei bemerkt werden Aktualisierungstoken nie mit diesem Flow gewährt, da client_id und client_secret (die zum Abrufen eines Aktualisierungstokens erforderlich wären) stattdessen zum Abrufen eines Zugriffstokens verwendet werden können.

Beim Fluss zur Gewährung von OAuth 2.0-Clientanmeldeinformationen kann ein Webdienst (ein vertraulicher Client) seine eigenen Anmeldeinformationen zum Authentifizieren verwenden, wenn ein anderer Webdienst aufgerufen wird, anstatt die Identität eines Benutzers anzunehmen. Für ein höheres Maß an Sicherheit erlaubt die Microsoft-Identitätsplattform dem aufrufenden Dienst auch die Authentifizierung mit einem Zertifikat oder einem föderierten Berechtigungsnachweis anstelle eines gemeinsamen Geheimnisses. Da die eigenen Anmeldeinformationen für die Anwendung verwendet werden, müssen diese Anmeldeinformationen sicher aufbewahrt werden. Sie sollten diese Anmeldeinformationen niemals im Quellcode veröffentlichen, in Webseiten einbetten oder in einer weit verbreiteten nativen Anwendung verwenden.

Im Flow zum Gewähren von Clientanmeldeinformationen werden Berechtigungen von einem Administrator direkt an die eigentliche Anwendung erteilt. Wenn die App einer Ressource ein Token präsentiert, macht die Ressource geltend, dass die App selbst für die Durchführung einer Aktion autorisiert ist, da an der Authentifizierung kein Benutzer beteiligt ist. In diesem Artikel werden die Schritte beschrieben, die zum Autorisieren einer Anwendung zum Aufrufen einer API erforderlich sind. Es wird aber auch die Vorgehensweise zum Abrufen der Token, die zum Aufrufen dieser API erforderlich sind erläutert.

Tipp

Diese Anforderung in Postman ausführen
Führen Sie diese Anforderung und weitere Funktionen in Postman aus. Vergessen Sie nicht, Token und IDs zu ersetzen.

Protokolldiagramm

Der gesamte Clientanmeldeinformations-Flow ist im folgenden Diagramm dargestellt. Wir beschreiben die einzelnen Schritte weiter unten in diesem Artikel.

Diagramm des Clientanmeldeinformations-Flows

Erhalten der direkten Autorisierung

Eine App empfängt die direkte Autorisierung für den Zugriff auf eine Ressource in der Regel auf zwei Arten:

Diese beiden Methoden sind in Azure AD am gebräuchlichsten und werden von uns für Clients und Ressourcen empfohlen, die den Clientanmeldeinformations-Flow ausführen. Eine Ressource kann auch wählen, dass die Clients auf andere Weise autorisiert werden sollen. Jeder Ressourcenserver kann die Methode auswählen, die am sinnvollsten für seine Anwendung ist.

Zugriffssteuerungslisten

Ein Ressourcenanbieter erzwingt möglicherweise eine Autorisierungsprüfung anhand einer Liste von Anwendungs-IDs (Client-IDs), die ihm bekannt sind, und erteilt eine bestimmte Zugriffsebene. Empfängt die Ressource ein Token von der Microsoft Identity Platform, kann sie das Token decodieren und die Anwendungs-ID des Clients aus den Ansprüchen appid und iss extrahieren. Anschließend vergleicht sie die Anwendung mit der von ihr verwalteten Zugriffssteuerungsliste. Granularität der Zugriffssteuerungsliste und Methode können sich zwischen Ressourcen erheblich unterscheiden.

Ein allgemeiner Anwendungsfall ist die Verwendung einer Zugriffssteuerungsliste zum Ausführen von Tests für eine Webanwendung oder eine Web-API. Die Web-API gewährt einem bestimmten Client möglicherweise nur eine Teilmenge der vollständigen Berechtigungen. Zum Ausführen von End-to-End-Tests auf der API wird aber ein Testclient erstellt, der Token von der Microsoft Identity Platform erhält und diese anschließend an die API sendet. Die API überprüft die Anwendungs-ID des Testclients anschließend anhand der Zugriffssteuerungsliste, um Vollzugriff auf die gesamte Funktionalität der API zu gewähren. Wenn Sie eine solche Zugriffssteuerungsliste verwenden, müssen Sie nicht nur den appid-Wert des Aufrufers überprüfen, sondern auch sicherstellen, dass der iss-Wert des Tokens vertrauenswürdig ist.

Diese Art der Autorisierung wird häufig für Daemons und Dienstkonten eingesetzt, die auf Daten zugreifen müssen, die sich im Besitz von Privatnutzern mit persönlichen Microsoft-Konten befinden. Für Daten, die Organisationen gehören, empfiehlt es sich, die erforderliche Autorisierung über Anwendungsberechtigungen zu erhalten.

Steuern von Token ohne den roles-Anspruch

Azure AD setzt nicht voraus, dass Anwendungen zum Abrufen von Token für eine andere Anwendung autorisiert sind, um dieses ACL-basierte Autorisierungsmuster zu aktivieren. Daher können nur für Apps gültige Token ohne einen roles-Anspruch ausgestellt werden. Bei Anwendungen, die APIs verfügbar machen, müssen zum Akzeptieren von Token Berechtigungsüberprüfungen implementiert werden.

Wenn Sie verhindern möchten, dass Anwendungen nur für Apps gültige Zugriffstoken ohne Rollen abrufen, sollten Sie sicherstellen, dass die Zuweisungsanforderungen für Ihre App aktiviert sind. Dadurch wird verhindert, dass Benutzer und Anwendungen ohne zugewiesene Rollen ein Token für diese Anwendung abrufen können.

Anwendungsberechtigungen

Anstelle von Zugriffssteuerungslisten können Sie APIs verwenden, um einen Satz von Anwendungsberechtigungen verfügbar zu machen. Eine Anwendungsberechtigung wird einer Anwendung von einem Administrator einer Organisation erteilt und kann nur für den Zugriff auf Daten verwendet werden, die sich im Besitz der jeweiligen Organisation und deren Mitarbeiter befinden. Microsoft Graph macht beispielsweise verschiedene Anwendungsberechtigungen für Folgendes verfügbar:

  • Lesen von E-Mails in allen Postfächern
  • Lesen und Schreiben von E-Mails in allen Postfächern
  • Senden von E-Mails als beliebiger Benutzer
  • Verzeichnisdaten lesen

Wenn Sie App-Rollen (Anwendungsberechtigungen) mit Ihrer eigenen API (und nicht mit Microsoft Graph) verwenden möchten, müssen Sie zunächst die im Azure-Portal in der App-Registrierung der API App-Rollen verfügbar machen. Konfigurieren Sie dann die erforderlichen App-Rollen, indem Sie diese Berechtigungen in der App-Registrierung Ihrer Clientanwendung auswählen. Wenn Sie in der App-Registrierung Ihrer API keine App-Rollen verfügbar gemacht haben, können Sie im Azure-Portal in der App-Registrierung Ihrer Clientanwendung keine Anwendungsberechtigungen für diese API angeben.

Wenn Sie sich als Anwendung authentifizieren (im Gegensatz zu einem Benutzer), können Sie keine delegierten Berechtigungen verwenden, weil es keinen Benutzer gibt, in dessen Namen die App agieren kann. Sie müssen Anwendungsberechtigungen (auch als App-Rollen bezeichnet) verwenden, die von einem Administrator oder vom Besitzer der API erteilt werden.

Weitere Informationen zu Anwendungsberechtigungen finden Sie unter Berechtigungen und Einwilligung.

Wenn Sie eine Anwendung erstellen, die Anwendungsberechtigungen verwendet, erfordert die App in der Regel eine Seite oder eine Sicht, auf der der Administrator Berechtigungen für die App genehmigt. Diese Seite kann Teil des Anmelde-Flows der App, Teil der App-Einstellungen oder ein dedizierter Flow „Verbinden“ sein. In vielen Fällen ist es sinnvoll, wenn die App diese Ansicht „Verbinden“ erst anzeigt, wenn ein Benutzer sich mit einem Geschäfts-, Schul- oder Unikonto von Microsoft angemeldet hat.

Durch das Anmelden des Benutzers bei Ihrer App können Sie die Organisation identifizieren, der der Benutzer angehört, bevor Sie ihn zur Genehmigung der Anwendungsberechtigungen auffordern. Auch wenn es nicht unbedingt erforderlich ist, können Sie für Ihre Benutzer auf diese Weise eine intuitivere Benutzeroberfläche erstellen. Gehen Sie gemäß den Tutorials zum Microsoft Identity Platform-Protokoll vor, um den Benutzer anzumelden.

Anfordern der Berechtigungen von einem Verzeichnisadministrator

Wenn Sie dazu bereit sind, vom Administrator der Organisation Berechtigungen anzufordern, können Sie den Benutzer zum Endpunkt für die Administratorzustimmung von Microsoft Identity Platform umleiten.

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/adminconsent?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&state=12345
&redirect_uri=http://localhost/myapp/permissions

Profitipp: Versuchen Sie, die folgende Anforderung in einem Browser einzufügen.

https://login.microsoftonline.com/common/adminconsent?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&state=12345&redirect_uri=http://localhost/myapp/permissions
Parameter Bedingung BESCHREIBUNG
tenant Erforderlich Der Verzeichnismandant, von dem Sie die Berechtigung anfordern möchten. Kann als GUID oder als Anzeigename bereitgestellt werden. Wenn Sie nicht wissen, zu welchem Mandanten der Benutzer gehört, und wenn der Benutzer sich bei jedem Mandanten anmelden können soll, verwenden Sie common.
client_id Erforderlich Die Anwendungs-ID (Client-ID) , die Ihrer App im Azure-Portal auf der Seite „App-Registrierungen“ zugewiesen wurde.
redirect_uri Erforderlich Der Umleitungs-URI, an den die Antwort zur Verarbeitung durch die App gesendet werden soll. Er muss genau mit einem der Umleitungs-URIs übereinstimmen, die Sie im Portal registriert haben, mit der Ausnahme, dass er URL-kodiert sein muss und zusätzliche Pfadsegmente enthalten kann.
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. Der Status wird 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.

An diesem Punkt erzwingt Azure AD, dass sich nur ein Mandantenadministrator anmelden kann, um die Anforderung abzuschließen. Der Administrator wird aufgefordert, alle direkten Anwendungsberechtigungen zu genehmigen, die Sie für Ihre App im App-Registrierungsportal angefordert haben.

Erfolgreiche Antwort

Wenn der Administrator die Berechtigungen für Ihre Anwendung genehmigt, lautet die erfolgreiche Antwort wie folgt:

GET http://localhost/myapp/permissions?tenant=a8990e1f-ff32-408a-9f8e-78d3b9139b95&state=state=12345&admin_consent=True
Parameter BESCHREIBUNG
tenant Der Verzeichnismandant, der Ihrer Anwendung die angeforderten Berechtigungen erteilt hat, im GUID-Format
state Ein in der Anforderung enthaltener Wert, der auch in der Tokenantwort zurückgegeben wird. Es kann sich um eine Zeichenfolge mit jedem beliebigen Inhalt handeln. Der Status wird 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.
admin_consent Legen Sie den Wert auf True fest.
Fehlerantwort

Wenn der Administrator die Berechtigungen für Ihre Anwendung nicht genehmigt, lautet die Fehlerantwort wie folgt:

GET http://localhost/myapp/permissions?error=permission_denied&error_description=The+admin+canceled+the+request
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 Sie die Grundursache eines Fehlers identifizieren können.

Nachdem Sie eine erfolgreiche Antwort vom App-Bereitstellungsendpunkt erhalten haben, erhält Ihre App die direkten Anwendungsberechtigungen, die sie angefordert hat. Als Nächstes können Sie ein Token für eine gewünschte Ressource anfordern.

Abrufen von Token

Sobald Sie die notwendige Autorisierung für Ihre Anwendung erhalten haben, können Sie mit dem Abrufen von Zugriffstoken für APIs fortfahren. Um ein Token über die Gewährung von Clientanmeldeinformationen zu erhalten, senden Sie eine POST-Anforderung an die /token-Microsoft Identity Platform:

Erster Fall: Zugriffstokenanforderung mit einem gemeinsamen Geheimnis

POST /{tenant}/oauth2/v2.0/token HTTP/1.1           //Line breaks for clarity
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_secret=sampleCredentia1s
&grant_type=client_credentials
# Replace {tenant} with your tenant!
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id=535fb089-9ff3-47b6-9bfb-4f1264799865&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=qWgdYAmab0YSkuL1qKv5bPX&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'
Parameter Bedingung BESCHREIBUNG
tenant Erforderlich Der Verzeichnismandant, der von der Anwendung für den Betrieb verwendet werden soll, im GUID- oder Domänennamensformat.
client_id Erforderlich Die Anwendungs-ID, die Ihrer App zugewiesen ist. Diese Informationen finden Sie in dem Portal, in dem Sie Ihre App registriert haben.
scope Erforderlich Bei dem Wert, der in dieser Anforderung für den scope-Parameter übergeben wird, muss es sich um den Ressourcenbezeichner (Anwendungs-ID-URI) der gewünschten Ressource mit dem Suffix .default handeln. Für das angegebene Microsoft Graph-Beispiel ist der Wert https://graph.microsoft.com/.default.
Dieser Wert weist die Microsoft Identity Platform an, von allen direkten Anwendungsberechtigungen, die Sie für Ihre App konfiguriert haben, ein Token für diejenigen auszustellen, die zur gewünschten Ressource gehören. Weitere Informationen zum /.default-Bereich finden Sie in der Dokumentation zu Zustimmungen.
client_secret Erforderlich Der geheime Clientschlüssel, den Sie im App-Registrierungsportal für Ihre App generiert haben. Der geheime Clientschlüssel muss vor dem Senden URL-codiert werden. Das Standardauthentifizierungsmuster der Bereitstellung von Anmeldeinformationen im Autorisierungsheader gemäß RFC 6749 wird ebenfalls unterstützt.
grant_type Erforderlich Muss auf client_credentials festgelegt sein.

Zweiter Fall: Zugriffstokenanforderung mit einem Zertifikat

POST /{tenant}/oauth2/v2.0/token HTTP/1.1               // Line breaks for clarity
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=97e0a5b7-d745-40b6-94fe-5f77d35c6e05
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials
Parameter Bedingung BESCHREIBUNG
tenant Erforderlich Der Verzeichnismandant, der von der Anwendung für den Betrieb verwendet werden soll, im GUID- oder Domänennamensformat.
client_id Erforderlich Die Anwendungs-ID (Client-ID), die Ihrer App zugewiesen ist.
scope Erforderlich Bei dem Wert, der in dieser Anforderung für den scope-Parameter übergeben wird, muss es sich um den Ressourcenbezeichner (Anwendungs-ID-URI) der gewünschten Ressource mit dem Suffix .default handeln. Für das angegebene Microsoft Graph-Beispiel ist der Wert https://graph.microsoft.com/.default.
Dieser Wert teilt der Microsoft Identity Platform mit, dass von allen direkten Anwendungsberechtigungen, die Sie für Ihre App konfiguriert haben, ein Token für diejenigen ausgestellt werden soll, die zur gewünschten Ressource gehören. Weitere Informationen zum /.default-Bereich finden Sie in der Dokumentation zu Zustimmungen.
client_assertion_type Erforderlich Der Wert muss auf urn:ietf:params:oauth:client-assertion-type:jwt-bearer festgelegt werden.
client_assertion Erforderlich Eine Assertion (ein JSON-Webtoken), 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.
grant_type Erforderlich Muss auf client_credentials festgelegt sein.

Die Parameter für die zertifikatbasierte Anforderung stimmen mit nur einer Ausnahme mit den Parametern für die Anforderung basierend auf einem gemeinsamen Geheimnis überein: der client_secret-Parameter wird durch die Parameter client_assertion_type und client_assertion ersetzt.

Dritter Fall: Anforderung eines Zugriffstokens mit einem föderierten Berechtigungsnachweis

POST /{tenant}/oauth2/v2.0/token HTTP/1.1               // Line breaks for clarity
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=97e0a5b7-d745-40b6-94fe-5f77d35c6e05
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials
Parameter Bedingung BESCHREIBUNG
client_assertion Erforderlich Eine Assertion (ein JWT oder JSON-Web-Token), die Ihre Anwendung von einem anderen Identitätsanbieter außerhalb der Microsoft-Identitätsplattform, wie Kubernetes, erhält. Die Spezifika dieses JWT müssen in Ihrer Anwendung als federated identity credential registriert werden. Lesen Sie über workload identity federation, um zu erfahren, wie Sie von anderen Identitätsanbietern generierte Assertions einrichten und verwenden können.

Alles in der Anfrage entspricht dem obigen zertifikatsbasierten Fluss, mit einer entscheidenden Ausnahme - der Quelle der client_assertion. Bei diesem Ablauf erstellt Ihre Anwendung die JWT-Assertion nicht selbst. Stattdessen verwendet Ihre Anwendung ein JWT, das von einem anderen Identitätsanbieter erstellt wurde. Dies wird als "workload identity federation" bezeichnet, bei der die Identität Ihrer Anwendungen in einer anderen Identitätsplattform verwendet wird, um Token innerhalb der Microsoft-Identitätsplattform zu erwerben. Dies eignet sich am besten für Cloud-übergreifende Szenarien, z. B. wenn Sie Ihre Rechenleistung außerhalb von Azure hosten, aber auf APIs zugreifen, die durch die Microsoft Identitätsplattform geschützt sind. Informationen zum erforderlichen Format von JWTs, die von anderen Identitätsanbietern erstellt werden, finden Sie unter Assertionsformat.

Erfolgreiche Antwort

Eine erfolgreiche Antwort von einer beliebigen Methode sieht wie folgt aus:

{
  "token_type": "Bearer",
  "expires_in": 3599,
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBP..."
}
Parameter BESCHREIBUNG
access_token Das angeforderte Zugriffstoken. Die App kann dieses Token zur Authentifizierung bei geschützten Ressourcen wie einer Web-API verwenden.
token_type Gibt den Wert des Tokentyps an. Die Microsoft Identity Platform unterstützt nur den Typ bearer.
expires_in Die Gültigkeitsdauer eines Zugriffstokens (in Sekunden).

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

Eine Fehlerantwort (400 Bad Request) sieht wie folgt aus:

{
  "error": "invalid_scope",
  "error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/.default is not valid.\r\nTrace ID: 255d1aef-8c98-452f-ac51-23d051240864\r\nCorrelation ID: fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7\r\nTimestamp: 2016-01-09 02:02:12Z",
  "error_codes": [
    70011
  ],
  "timestamp": "2016-01-09 02:02:12Z",
  "trace_id": "255d1aef-8c98-452f-ac51-23d051240864",
  "correlation_id": "fb3d2015-bc17-4bb9-bb85-30c5cf1aaaa7"
}
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 Sie die Hauptursache eines Authentifizierungsfehlers identifizieren können
error_codes Eine Liste der STS-spezifischen Fehlercodes, die bei der Diagnose helfen können
timestamp Die Uhrzeit, zu der der Fehler aufgetreten ist
trace_id Ein eindeutiger Bezeichner für die Anforderung, der bei der Diagnose hilfreich sein kann
correlation_id Ein eindeutiger Bezeichner für die Anforderung, der bei der komponentenübergreifenden Diagnose hilfreich sein kann

Verwenden eines Tokens

Da Sie jetzt ein Token abgerufen haben, können Sie dieses Token verwenden, um Anforderungen an die Ressource zu stellen. Wenn das Token abläuft, wiederholen Sie die Anforderung an den /token-Endpunkt, um ein neues Zugriffstoken abzurufen.

GET /v1.0/me/messages
Host: https://graph.microsoft.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
# Pro tip: Try the following command! (Replace the token with your own.)

curl -X GET -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbG...." 'https://graph.microsoft.com/v1.0/me/messages'

Codebeispiele und anderes Dokumentationsmaterial

Lesen Sie die Übersichtsdokumentation zu Clientanmeldeinformationen aus der Microsoft-Authentifizierungsbibliothek.

Beispiel Plattform BESCHREIBUNG
active-directory-dotnetcore-daemon-v2 .NET Core 2.1-Konsole Eine einfache .NET Core-Anwendung, die die Benutzer eines Mandanten anzeigt, der Microsoft Graph unter Verwendung der Anwendungsidentität (statt im Auftrag eines Benutzers) abfragt. Das Beispiel veranschaulicht außerdem die Variante, bei der Zertifikate für die Authentifizierung verwendet werden.
active-directory-dotnet-daemon-v2 ASP.NET MVC Eine Webanwendung, die Daten aus Microsoft Graph unter Verwendung der Anwendungsidentität (statt im Auftrag eines Benutzers) synchronisiert.
ms-identity-javascript-nodejs-console Node.js-Konsole Eine einfache Node.js-Anwendung, die die Benutzer eines Mandanten anzeigt. Hierzu wird Microsoft Graph unter Verwendung der Anwendungsidentität abgefragt.