Verstehen der Berechtigungen und Zustimmung zu Microsoft Graph

  • 6 Minuten

Um eine Kundenanwendung entwickeln zu können, die Microsoft 365-Daten abrufen kann, müssen Sie verstehen, wie Berechtigungen und Zustimmungen in Microsoft Graph funktionieren. Sie möchten die richtigen Entscheidungen darüber treffen, auf welche Daten Ihre Anwendung zugreifen kann und auf welche nicht. Beispiel: Wenn Sie einen angemeldeten Verkäufer in bevorstehenden Besprechungen anzeigen möchten, sollten Sie der Anwendung die Berechtigung für den Zugriff auf die Kalenderdaten von Microsoft 365 erteilen.

Anwendungen fordern Berechtigung an, um auf bestimmte Microsoft 365-Ressourcen über Microsoft Graph zuzugreifen. Diese Anforderungen können im Voraus (bei der Registrierung der Anwendung) oder dynamisch (während der Ausführung der Anwendung) erfolgen. Wenn eine Anwendung die Berechtigung anfordert, muss ein Benutzer oder Administrator der Berechtigung zustimmen, bevor Microsoft Graph Anforderungen autorisiert.

Es gibt drei Hauptkonzepte, die Sie verstehen müssen, wenn Ihre Anwendung mit Microsoft Graph interagieren muss:

  • Microsoft Graph-Berechtigungen oder -Bereiche
  • Berechtigungstypen
  • Zugriffstoken

Microsoft Graph-Berechtigungen oder -Bereiche

Microsoft Graph-Berechtigungen enthalten Bereiche, die den Zugriff Ihrer App auf bestimmte Ressourcen, wie z. B. Benutzer, E-Mail und Dateien, steuern. Bereiche steuern auch die Vorgänge, die für diese Ressourcen ausgeführt werden können. Das folgende Beispielmuster definiert eine Berechtigung für einen Microsoft Graph-Vorgang für eine Ressource:

Resource-name.operation.constraint

Zum Beispiel gewährt User.Read.All einer Anwendung die Berechtigung, das Profil aller Benutzer in einem Verzeichnis zu lesen. Um das Profil eines angemeldeten Benutzers zu lesen, ist die erforderliche Berechtigung User.Read.

Berechtigungstypen

Es gibt zwei Arten von Berechtigungen in Microsoft Entra ID:

  • Ihre Anwendung verwendet die delegierte Berechtigung, wenn sie einen Microsoft Graph-Aufruf im Auftrag des Benutzers abruft. Der Benutzer kann einigen Berechtigungsbereichen zustimmen, z. B. User.Read. Einige Berechtigungsbereiche sind jedoch hoch privilegiert und erfordern die Zustimmung eines Administrators. Ein Beispiel für einen hoch privilegierten Berechtigungsbereich ist Channel.Delete.All, der Kanäle in jedem Team im Auftrag des angemeldeten Benutzers löscht.

    Das einfachste Beispiel für einen delegierten Berechtigungsbereich ist User.Read, der erforderlich ist, um den /me-Endpunkt aufzurufen. In Microsoft Graph verwenden alle API-Aufrufe mit /me den Kontext des aktuell angemeldeten Benutzers.

  • Die Anwendungsberechtigung erfordert keinen in der Anwendung angemeldeten Benutzer. Dies wird häufig verwendet, wenn ein Benutzer nicht vorhanden ist, z. B. in einem Hintergrundprozess, oder um Berechtigungen zu erhöhen. Ein Administrator stimmt der Berechtigung im Voraus zu.

    Ein Beispiel für einen Anwendungsberechtigungsbereich ist Calendars.ReadWrite. Dadurch kann die App Ereignisse aller Kalender ohne angemeldeten Benutzer erstellen, lesen, aktualisieren und löschen. Sie können eine /me-API nicht für einen Anwendungsberechtigungsbereich verwenden, da kein angemeldeter Benutzer zum Abrufen dieser Informationen verfügbar ist.

Zugriffstoken

Nachdem die Anwendung die Berechtigung angefordert und ein Benutzer oder Administrator seine Zustimmung gegeben hat, kann die Anwendung ein Zugriffstoken von der Microsoft Identity Platform abrufen. Sie können sich den Zugangstoken wie eine Kinokarte vorstellen, die Sie einem Kinomitarbeiter geben, um zu beweisen, dass Sie für den Kinobesuch bezahlt haben. Ihre Anwendung gibt Microsoft Graph ein Zugriffstoken, um nachzuweisen, dass sie über die Berechtigung zum Zugriff auf Microsoft 365-Daten verfügt.

Microsoft Graph erfordert ein gültiges Zugriffstoken im HTTP-Header jeder Anforderung. Er wird im Autorisierungsheader jeder HTTP-Anforderung mit dem Wort "Bearer" und einem Leerzeichen vor ihr übergeben. Dies ist eine Erinnerung daran, wie bei einer Kinokarte, dass der Inhaber das Zugriffstoken verwenden kann. Das heißt, jeder, der das Ticket hat, kann ohne Identitätsnachweis eintreten. Aus diesem Grund erfordert Microsoft Graph für alle Anforderungen eine HTTPS-Verschlüsselung. Ebenso wie Kinokarten sind Zugriffstoken nur für einen kurzen Zeitraum gültig, in der Regel eine Stunde.

Hier ist ein Beispiel dafür, wie ein Autorisierungsheader für eine Microsoft Graph-Anforderung aussehen kann:

GET https://graph.microsoft.com/v1.0/me/ HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer EwAoA8l6BAAU ... 7PqHGsykYj7A0XqHCjbKKgWSkcAg==