Teilen über

Microsoft Identity Platform und der Fluss von OAuth 2.0-Clientanmeldeinformationen

  • Artikel

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. Die Gewährung von OAuth 6749-Clientanmeldeinformationen, die in RFC 6749 angegeben ist und gelegentlich als zweibeinige OAuth-Autorisierung bezeichnet wird, kann für den Zugriff auf webgehostete Ressourcen über die Identität einer Anwendung verwendet werden. Dieser Typ wird häufig für Server-zu-Server-Interaktionen verwendet, die ohne Benutzereingriff im Hintergrund ausgeführt werden müssen, und wird häufig als Daemons oder Dienstkonten bezeichnet.

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 beiden Schritte behandelt, die für Folgendes erforderlich sind:

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. Weitere Informationen finden Sie auch unter Beispiel-Apps, 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.

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 der Anwendung verwendet werden, müssen diese Anmeldeinformationen sicher aufbewahrt werden. Veröffentlichen Sie diese Anmeldeinformationen niemals in Ihrem Quellcode, betten Sie sie nicht in Webseiten ein, und verwenden Sie sie nicht in weit verbreiteten nativen Anwendungen.

Protokolldiagramm

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

Diagram showing the client credentials flow

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 Microsoft Entra ID 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 können Sie einen Testclient erstellen, 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

Microsoft Entra ID 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. Diese werden einer Anwendung von einem Administrator einer Organisation gewährt und können 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 im Microsoft Entra Admin Center in der App-Registrierung der API die 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 Microsoft Entra Admin Center 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 Verbinden-Flow sein. Oft ist es sinnvoll, dass die App diese Verbinden-Ansicht 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=00001111-aaaa-2222-bbbb-3333cccc4444
&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=00001111-aaaa-2222-bbbb-3333cccc4444&state=12345&redirect_uri=http://localhost/myapp/permissions
Parameter Condition 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 auf der Benutzeroberfläche „App-Registrierungen“ im Microsoft Entra Admin Center zugewiesen ist.
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 Microsoft Entra ID, 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=aaaabbbb-0000-cccc-1111-dddd2222eeee&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. Es lassen sich verschiedene Fälle unterscheiden:

Erster Fall: Zugriffstokenanforderung mit einem gemeinsamen Geheimnis

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

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

# Replace {tenant} with your tenant!
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id=00001111-aaaa-2222-bbbb-3333cccc4444&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=A1bC2dE3f...&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'
Parameter Condition 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. Alle enthaltenen Bereiche müssen für eine einzelne Ressource sein. Das Einschließen von Bereichen für mehrere Ressourcen wird zu einem Fehler führen.
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:443
Content-Type: application/x-www-form-urlencoded

scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&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 Condition 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. Alle enthaltenen Bereiche müssen für eine einzelne Ressource sein. Das Einschließen von Bereichen für mehrere Ressourcen wird zu einem Fehler führen.
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_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:443
Content-Type: application/x-www-form-urlencoded

scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=11112222-bbbb-3333-cccc-4444dddd5555&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 Condition 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: 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": "YYYY-MM-DD HH:MM:SSZ",
  "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333",
  "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
}
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/users HTTP/1.1
Host: graph.microsoft.com:443
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbG...

Führen Sie den folgenden Befehl in Ihrem Terminal aus, und stellen Sie sicher, dass Sie das Token durch Ihr eigenes ersetzen.

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

Codebeispiele und anderes Dokumentationsmaterial

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

Beispiel Plattform BESCHREIBUNG
active-directory-dotnetcore-daemon-v2 .NET 6.0 oder höher Eine ASP.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 Node.js-Anwendung, die die Benutzer eines Mandanten anzeigt. Hierzu wird Microsoft Graph unter Verwendung der Anwendungsidentität abgefragt.