Freigeben über


Übersicht über Microsoft Graph Berechtigungen

Bevor die Microsoft Identity Platform Ihre App für den Zugriff auf Daten in der Microsoft-Cloud autorisieren kann, müssen der App die erforderlichen Berechtigungen gewährt werden. Ebenso müssen der App die erforderlichen Berechtigungen gewährt werden, bevor die Microsoft Identity Platform Ihre App für den Zugriff auf Daten über Microsoft Graph autorisieren kann.

Eine Möglichkeit, einer App die Berechtigungen zu gewähren, die sie für den Zugriff und die Arbeit mit Ihren Daten über Microsoft Graph benötigt, besteht darin, ihr Microsoft Graph-Berechtigungen zuzuweisen. Eine andere Möglichkeit ist die Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) wie Microsoft Entra RBAC. In einigen Fällen sind für den Zugriff auf Daten über Microsoft Graph-APIs sowohl Microsoft Graph-Berechtigungen als auch RBAC-Berechtigungen erforderlich.

In diesem Artikel werden Microsoft Graph-Berechtigungen vorgestellt und Anleitungen für deren Verwendung bereitgestellt. Die vollständige Liste der von Microsoft Graph bereitgestellten Berechtigungen finden Sie in der Referenz zu Microsoft Graph-Berechtigungen.

Weitere Informationen zur Funktionsweise von Berechtigungen finden Sie im folgenden Video.

Berechtigungstypen

Microsoft Graph unterstützt zwei Zugriffsszenarien, delegierten Zugriff und reinen App-Zugriff.. Beim delegierten Zugriff ruft die App Microsoft Graph im Namen eines angemeldeten Benutzers auf. Beim reinen App-Zugriff ruft die App Microsoft Graph mit einer eigenen Identität ohne angemeldeten Benutzer auf.

Zur Unterstützung dieser Zugriffsszenarien stellt Microsoft Graph delegierte Berechtigungen und Anwendungsberechtigungenbereit.

Delegierte Berechtigungen

Delegierte Berechtigungen, auch als Bereiche bezeichnet, werden im delegierten Zugriffsszenario verwendet. Dabei handelt es sich um Berechtigungen, die es der Anwendung ermöglichen, im Namen eines angemeldeten Benutzers zu handeln. Die Anwendung kann jedoch auf nichts zugreifen, auf das der angemeldete Benutzer nicht zugreifen konnte.

Beispielsweise wurde einer Anwendung die delegierte Berechtigung Files.Read.All im Namen von Tom, einem Benutzer, erteilt. Die Anwendung kann nur alle Dateien im organization lesen, auf die Tom bereits zugreifen kann. Tom kann möglicherweise auf die Dateien zugreifen, da er über eine der folgenden Möglichkeiten über Berechtigungen verfügt:

  • Tom hat die Dateien erstellt oder besitzt diese.
  • Die Dateien wurden direkt mit Tom oder indirekt über eine Team- oder Gruppenmitgliedschaft freigegeben.
  • Tom wurden Berechtigungen über ein unterstütztes RBAC-System erteilt.

Daher werden in einem delegierten Szenario die Berechtigungen, die eine App hat, um im Namen eines Benutzers zu handeln, durch die Microsoft Graph-Berechtigungen bestimmt, die der App gewährt wurden, und den eigenen Berechtigungen des Benutzers.

In einem Szenario mit delegiertem Zugriff kann eine App Benutzern ermöglichen, sich mit ihren persönlichen Microsoft-Konten anzumelden, z. B. mit Outlook.com-, Geschäfts-, Schul- oder Unikonten, oder beide Kontotypen zuzulassen. Alle delegierten Berechtigungen gelten für Geschäfts-, Schul- oder Unikonten, aber nicht alle für persönliche Microsoft-Konten. Verwenden Sie die Microsoft Graph-Berechtigungsreferenz, um delegierte Berechtigungen zu identifizieren, die für persönliche Microsoft-Konten gültig sind.

Wenn sich ein Benutzer bei einer App anmeldet, erhält er oder in einigen Fällen ein Administrator die Möglichkeit, den delegierten Berechtigungen zuzustimmen. Wenn sie ihre Zustimmung erteilen, kann die App innerhalb der Grenzen der Benutzerberechtigungen auf Ressourcen und APIs zugreifen.

Hinweis

Berechtigungen, die über Microsoft Entra integrierten Rollen gewährt werden, beschränken die App nicht nur auf das Aufrufen von Microsoft Graph-APIs.

Anwendungsberechtigungen

Anwendungsberechtigungen, die auch als App-Rollenbezeichnet werden, werden im Szenario für den reinen App-Zugriff verwendet, ohne dass ein angemeldeter Benutzer vorhanden ist. Die Anwendung kann auf alle Daten zugreifen, denen die Berechtigung zugeordnet ist. Beispielsweise kann eine Anwendung, der die Anwendungsberechtigung Files.Read.All gewährt wurde, jede Datei im organization lesen.

Für Apps, die ohne angemeldeten Benutzer auf Ressourcen und APIs zugreifen, stimmt ein Administrator den Anwendungsberechtigungen zu, wenn die App im Mandanten oder über die Microsoft Entra Admin Center installiert wird. Nur Administrator für privilegierte Rollen und globaler Administrator können anwendungsberechtigungen zustimmen.

Neben der Zuweisung von Microsoft Graph-Anwendungsberechtigungen können einer App auch die benötigten Berechtigungen durch eine der folgenden Bedingungen gewährt werden:

  • Wenn der App der Besitz der Ressource zugewiesen wird, die sie verwalten möchte.
  • Wenn der App Berechtigungen über ein RBAC-System oder benutzerdefinierte Administratorrollen zugewiesen werden.

Hinweis

Berechtigungen, die über Microsoft Entra integrierten Rollen gewährt werden, beschränken die App nicht nur auf das Aufrufen von Microsoft Graph-APIs.

Vergleich von delegierten Berechtigungen und Anwendungsberechtigungen

Kategorie Delegierte Berechtigungen Anwendungsberechtigungen
Typen von Apps Web-App / Mobil / Single-Page-App (SPA) Web/Daemon
Zugriffskontext Im Namen eines Benutzers zugreifen Ohne Benutzer zugreifen
Wer kann zustimmen?
  • Benutzer können für ihre Daten zustimmen
  • Administratoren können für alle Benutzer zustimmen
  • Nur Administrator kann zustimmen
    Andere Namen
  • Scopes
  • OAuth2-Berechtigungen
  • App-Rollen
  • Nur-App-Berechtigungen
  • Berechtigungen für direkten Zugriff
  • Ergebnis der Zustimmung oAuth2PermissionGrant-Objekt appRoleAssignment-Objekt
    Unterstützte signInAudience-typen AzureADMyOrg
    AzureADMultipleOrgs
    AzureADandPersonalMicrosoftAccount
    PersonalMicrosoftAccount
    AzureADMyOrg
    AzureADMultipleOrgs
    AzureADandPersonalMicrosoftAccount

    Das folgende Bild veranschaulicht die Berechtigungen einer App in delegierten und reinen App-Zugriffsszenarien.

    Darstellung von Anwendungsberechtigungen in Szenarien mit delegiertem oder reinem App-Zugriff.

    Benennungsmuster für Berechtigungen

    Microsoft Graph stellt granulare Berechtigungen bereit, mit denen Sie den Zugriff von Apps auf Microsoft Graph-Ressourcen wie Benutzer, Gruppen und E-Mails steuern können. Diese Berechtigungen werden nach folgendem Muster benannt:

    {resource}. {operation}. {constraint}

    Wert Beschreibung Beispiele
    {resource} Bezieht sich auf eine Microsoft Graph-Ressource, auf die die Berechtigung den Zugriff zulässt. Beispielsweise die user Ressource. User, Application oder Group
    {operation} Bezieht sich auf die Microsoft Graph-API-Vorgänge, die für die von der Ressource bereitgestellten Daten zulässig sind. Beispielsweise Read für schreibgeschützte Vorgänge oder ReadWrite für Lese-, Erstellungs-, Aktualisierungs- und Löschvorgänge. Read, ReadBasic, ReadWrite, Create, Manageoder Migrate
    {constraint} Bestimmt den potenziellen Umfang des Zugriffs, den eine App innerhalb des Verzeichnisses hat. Dieser Wert darf nicht explizit deklariert werden. Wenn sie nicht deklariert ist, ist die Standardeinschränkung auf Daten beschränkt, die dem angemeldeten Benutzer gehören. All, AppFolder, OwnedBy, Selected, Shared, Hidden

    Beispiele:

    • User.Read – Ermöglicht der App, Informationen über den angemeldeten Benutzer zu lesen.
    • Application.ReadWrite.All – Ermöglicht der App, alle Anwendungen im Mandanten zu verwalten.
    • Application.ReadWrite.OwnedBy – Ermöglicht der App, nur die Anwendungen zu verwalten, die sie erstellt oder besitzt.
    • Group.Create – Ermöglicht der Anwendung, neue Gruppen zu erstellen, diese jedoch nicht zu ändern oder zu löschen.
    • Member.Read.Hidden – Ermöglicht der App, versteckte Mitgliedschaften zu lesen

    Die vollständige Liste der von Microsoft Graph bereitgestellten Berechtigungen finden Sie unter Referenz zu Microsoft Graph-Berechtigungen.

    RSC ist ein Autorisierungsframework, das es ermöglicht, bereichsbezogenen Zugriff auf die Daten zu gewähren, die von einer Ressource verfügbar gemacht werden. Über RSC kann ein autorisierter Benutzer einer App Zugriff auf die Daten einer bestimmten instance eines Ressourcentyps gewähren. Sie müssen nicht jedem instance des Ressourcentyps im gesamten Mandanten App-Zugriff gewähren.

    RSC-Berechtigungen sind auch für die Zustimmung verfügbar und werden nur von einer Teilmenge der features unterstützt, die über Microsoft Graph verfügbar sind, z. B. Teams, Chats und Nachrichten. Erfahren Sie mehr über RSC-Berechtigungen , oder entdecken Sie die vollständige Liste der verfügbaren RSC-Berechtigungen.

    Eingeschränkte Informationen für unzugängliche Mitgliedsobjekte zurückgegeben

    Containerobjekte, z. B. Gruppen, unterstützen Mitglieder verschiedener Typen, z. B. Benutzer und Geräte. Wenn eine Anwendung mit den richtigen Berechtigungen die Mitgliedschaft eines Containerobjekts abfragt, empfängt sie eine 200 OK Antwort und eine Sammlung von Objekten. Wenn die App jedoch nicht über die Berechtigungen zum Lesen eines bestimmten Objekttyps im Container verfügt, werden Objekte dieses Typs zurückgegeben, jedoch mit eingeschränkten Informationen, z. B. können nur der Objekttyp und die ID zurückgegeben werden, und andere Eigenschaften werden als nullangegeben. Für die Objekttypen, für die die App über Leseberechtigungen verfügt, werden vollständige Informationen zurückgegeben.

    Dieses Prinzip wird auf alle Beziehungen angewendet, die den directoryObject-Typ aufweisen. Beispiele hierfür sind /groups/{id}/members, /users/{id}/memberOfund me/ownedObjects.

    Beispielsweise kann eine Gruppe Benutzer, Gruppen, Anwendungen, Dienstprinzipale, Geräte und Kontakte als Mitglieder haben. Einer App wird die Berechtigung GroupMember.Read.All mit den geringsten Berechtigungen für Gruppenmitglieder auflisten gewährt. Im Antwortobjekt werden nur die Eigenschaften id und @odata.type für alle zurückgegebenen Member aufgefüllt. Die anderen Eigenschaften werden als nullangegeben. Für diese API:

    • Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Benutzer sind, benötigt die App mindestens die Berechtigung User.ReadBasic.All .
    • Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Gruppen sind, benötigt die App mindestens die GroupMember.Read.All-Berechtigung .
    • Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Geräte sind, benötigt die App mindestens die Berechtigung Device.Read.All usw.
    • Alternativ zu den einzelnen Berechtigungen auf Ressourcenebene kann der App jedoch mindestens die Berechtigung Directory.Read.All zugewiesen werden, um alle Eigenschaften für alle Membertypen zu lesen.

    Beispiel

    Anforderung

    GET https://graph.microsoft.com/v1.0/groups/{id}/members
    

    Antwort

    Das folgende Objekt ist ein Beispiel für die Antwort:

    {
    "@odata.context":"https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
        "value":[
            {
                "@odata.type":"#microsoft.graph.user",
                "id":"69d035a3-29c9-469f-809d-d21a4ae69e65",
                "displayName":"Adele Vance",
                "createdDateTime":"2019-09-18T09:06:51Z",
            },
            {
                "@odata.type":"#microsoft.graph.group",
                "id":"c43a7cc9-2d95-44b6-bf6a-6392e41949b4",
                "displayName":"All Company",
                "description":null,
                "createdDateTime":"2019-10-24T01:34:35Z"
            },
            {
                "@odata.type":"#microsoft.graph.device",
                "id": "d282309e-f91d-43b6-badb-9e68aa4b4fc8",
                "accountEnabled":null,
                "deviceId":null,
                "displayName":null,
                "operatingSystem":null,
                "operatingSystemVersion":null
            }
        ]
    }
    

    Bewährte Methoden für die Verwendung von Microsoft Graph Berechtigungen

    Microsoft Graph stellt granulare Berechtigungen bereit, die es einer App ermöglichen, nur die Berechtigungen anzufordern, die sie zum Funktionieren benötigt. Granulare Berechtigungen ermöglichen es Ihnen, das Prinzip der geringsten Rechte anzuwenden, wenn Sie einer App Berechtigungen zuweisen und gewähren, indem Sie der App die Mindestberechtigung erteilen, die sie für den Vorgang benötigt.

    Betrachten Sie die folgenden Beispiele:

    • Eine App muss nur die Profilinformationen des angemeldeten Benutzers lesen. Die App benötigt nur die Berechtigung User.Read.Dabei handelt es sich um die Berechtigung mit den geringsten Berechtigungen für den Zugriff auf die Informationen des angemeldeten Benutzers. Wenn der App die Berechtigung User.ReadWrite erteilt wird, wird sie überprivilegiert, da die App das Profil des Benutzers nicht aktualisieren muss.
    • Eine App muss die Gruppen im Mandanten ohne angemeldeten Benutzer lesen. Die App benötigt nur die GroupMember.Read.All-Anwendungsberechtigung , bei der es sich um die Berechtigung mit den geringsten Berechtigungen zum Lesen von Gruppen im Mandanten ohne angemeldeten Benutzer handelt.
    • Eine App muss einen Kalender des angemeldeten Benutzers lesen oder in diesen schreiben. Die App verwaltet dynamische Aufträge und synchronisiert aus dem Outlook-Kalender des Benutzers, um die App auf dem neuesten Stand zu halten, um Aufträge für den Benutzer zu planen. Wbwohl zum Abrufen der Kalenderdaten des Benutzers Calendars.Read erforderlich ist, benötigt das Aktualisieren des Kalenders mit geplanten Aufträgen eine höhere Berechtigung, Calendars.ReadWrite. In diesem Fall sollte die App Calendars.ReadWrite anfordern.

    Eine Anwendung mehr Berechtigungen zu gewähren, als sie benötigt, ist eine schlechte Sicherheitsmaßnahme, die die Angriffsfläche der App erhöht und sie nicht autorisiertem und unbeabsichtigtem Zugriff auf Daten oder Vorgänge aussetzt. Darüber hinaus kann das Anfordern von mehr Berechtigungen als erforderlich dazu führen, dass Benutzer keine Zustimmung zu einer App erteilen, was sich auf die Einführung und Nutzung einer App auswirkt.

    Wenden Sie beim Zuweisen und Gewähren von Microsoft Graph-Berechtigungen für eine App das Prinzip der geringsten Rechte an. Weitere Informationen finden Sie unter Verbessern der Sicherheit mit dem Prinzip der geringsten Rechte und Erstellen von Apps, die Identität durch Berechtigungen und Zustimmung schützen.

    Mit Vorsicht zu verwendende Berechtigungen

    Einige Microsoft Graph-Berechtigungen gewähren Zugriff auf einen größeren Bereich von Daten oder Vorgängen als andere. Verwenden Sie solche Berechtigungen mit Vorsicht. Beispielsweise ist die Berechtigung Directory.AccessAsUser.All die höchste privilegierte delegierte Berechtigung, die Zugriff auf fast alle API-Vorgänge in Microsoft Entra ID gewährt. Die Berechtigung Directory.ReadWrite.All ist in der Berechtigungsrangfolge an zweiter Position. Directory.Read.All ist die schreibgeschützte Berechtigung mit den höchsten Berechtigungen für Microsoft Entra ID Ressourcen. Diese Berechtigungen sollten mit Vorsicht und nur bei Bedarf verwendet werden. Verwenden Sie stattdessen immer Berechtigungen mit weniger privilegierten Optionen.

    In der API-Referenzdokumentation zu Microsoft Entra ID Ressourcen werden einige dieser berechtigungen mit höheren Berechtigungen möglicherweise absichtlich aus der Tabelle der Berechtigungen ausgeschlossen, die für den Zugriff auf die API unterstützt werden.

    Darüber hinaus ist die Globale Administratorrolle die integrierte Rolle mit den höchsten Berechtigungen in Microsoft Entra ID. In der API-Referenzdokumentation wird diese Rolle absichtlich aus der Liste der Rollen ausgeschlossen, die für den Zugriff auf die API zugunsten von Rollen mit geringeren Berechtigungen unterstützt werden.

    Grenzwerte für angeforderte Berechtigungen pro App

    Microsoft Entra ID begrenzt die Anzahl der Berechtigungen, die von einer Client-App angefordert und genehmigt werden können. Diese Grenzwerte hängen vom signInAudience Wert für eine App ab, der im Manifest der App angezeigt wird.

    signInAudience Zulässige Benutzer Maximale Berechtigungen, welche die App anfordern kann Maximale Microsoft Graph-Berechtigungen, welche die App anfordern kann Maximale Berechtigungen, die in einer einzelnen Anforderung genehmigt werden können
    AzureADMyOrg Benutzer aus der Organisation, in der die App registriert ist 400 400 Etwa 155 delegierte Berechtigungen und etwa 300 Anwendungsberechtigungen
    AzureADMultipleOrgs Benutzer aus einer beliebigen Microsoft Entra-Organisation 400 400 Etwa 155 delegierte Berechtigungen und etwa 300 Anwendungsberechtigungen
    PersonalMicrosoftAccount Privatanwender (z. B. Outlook.com- oder Live.com-Konten) 30 30 30
    AzureADandPersonalMicrosoftAccount Heimanwender und Benutzer aus einer beliebigen Azure AD-Organisation 30 30 30

    Abrufen von Berechtigungs-IDs über Microsoft Graph

    Um Berechtigungen mithilfe der Azure CLI, PowerShell oder Infrastruktur als Codeframework festzulegen, benötigen Sie möglicherweise den Bezeichner für die Berechtigung, die Sie anstelle des Namens verwenden möchten. Die Berechtigungsreferenz listet IDs für alle Microsoft Graph-Berechtigungen auf. Alternativ können Sie Informationen zu allen Microsoft Graph-Berechtigungen programmgesteuert über die Get servicePrincipal-API in Microsoft Graph lesen. Das folgende Beispiel zeigt eine Anfrage.

    GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')?$select=id,appId,displayName,appRoles,oauth2PermissionScopes,resourceSpecificApplicationPermissions
    

    Die Objekte appRoles, oauth2PermissionScopes und resourceSpecificApplicationPermissions speichern die anwendungsspezifischen, delegierten bzw. ressourcenspezifischen Zustimmungsberechtigungen.