Ü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.

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 nie auf etwas 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 in der Organisation 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 mit ihm geteilt.
  • Tom wurden Berechtigungen über ein rollenbasiertes Zugriffskontrollsystem (RBAC) wie Microsoft Entra RBAC 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 durch die eigenen Berechtigungen des Benutzers.

In einem Szenario mit delegiertem Zugriff kann eine App Benutzern ermöglichen, sich mit ihren persönlichen Microsoft-Konten wie Outlook.com, Geschäfts-, Schul- oder Unikonten anzumelden 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 Files.Read.All- Anwendungsberechtigung erteilt wurde, jede Datei in der Organisation lesen.

Für Apps, die ohne angemeldeten Benutzer auf Ressourcen und APIs zugreifen, können die Anwendungsberechtigungen von einem Administrator genehmigt werden, wenn die App im Mandanten oder über das Microsoft Entra Admin Center installiert wird. Nur ein Administrator kann 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 eine integrierte Microsoft Entra-Rolle 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 appRoleAssignment
    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 haben wird. 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.

    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 sind: /groups/{id}/members, /users/{id}/memberOf oder me/ownedObjects.

    Beispielszenario

    Die Mitglieder einer Gruppe sind Benutzer, Gruppen und Geräte. Einer App wurden die Microsoft Graph User.Read.All- und Group.Read.All-Berechtigungen erteilt. Die App ruft die API zum Auflisten von Gruppenmitgliedern auf, um die Mitglieder der Gruppe abzurufen.

    Zum Lesen der grundlegenden Eigenschaften der Mitglieder einer Gruppe, die Benutzer sind, benötigt die App mindestens die User.Read.All-Berechtigung. Zum Lesen der grundlegenden Eigenschaften der Mitglieder einer Gruppe, die Gruppen sind, benötigt die App mindestens die Group.Read.All-Berechtigung. Zum Lesen der grundlegenden Eigenschaften der Mitglieder einer Gruppe, die Geräte sind, benötigt die App mindestens die Device.Read.All-Berechtigung.

    Denn die App hat in der Antwort nur Zugriffsrechte auf Benutzer- und Gruppenobjekte in der Gruppe, aber nicht auf Geräteobjekte:

    • Alle grundlegenden Eigenschaften der Benutzer- und Gruppenmitgliedsobjekte werden zurückgegeben.
    • Für die Gerätemitgliedsobjekte werden nur der Objekttyp und die Objekt-ID zurückgegeben, aber alle sonstigen Eigenschaften haben den Wert NULL.

    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 AnwendungsberechtigungGroup.Read.All. Dabei handelt es sich um die Berechtigung mit den geringsten Berechtigungen zum Lesen von Gruppen im Mandanten ohne angemeldeten Benutzer.
    • 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.

    Einer Anwendung mehr Berechtigungen zu gewähren, als sie benötigt, ist eine schlechte Sicherheitsmaßnahme, die eine App dem unbefugten und unbeabsichtigten 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.

    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.