Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Bevor die Microsoft Identity Platform Ihre App für den Zugriff auf Daten in der Microsoft-Cloud autorisieren kann, müssen Sie der App die erforderlichen Berechtigungen erteilen. Ebenso müssen Sie der App die erforderlichen Berechtigungen erteilen, 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, funktionieren im Szenario mit delegiertem Zugriff. Mit diesen Berechtigungen kann die Anwendung im Namen eines angemeldeten Benutzers handeln. Die Anwendung kann jedoch auf nichts zugreifen, auf das der angemeldete Benutzer nicht zugreifen konnte.
Beispielsweise ruft eine Anwendung die delegierte Berechtigung Files.Read.All im Namen von Tom, einem Benutzer, ab. 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, auch als App-Rollen bezeichnet, funktionieren im Reinen App-Zugriffsszenario, ohne dass ein angemeldeter Benutzer anwesend 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 werden einer App möglicherweise auch die erforderlichen Berechtigungen durch eine der folgenden Bedingungen erteilt:
- 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? | Nur Administrator kann zustimmen | |
| Andere Namen | ||
| 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.
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 folgen dem Benennungsmuster:
{resource}. {operation}. {constraint}
| Wert | Beschreibung | Beispiele |
|---|---|---|
{resource} |
Bezieht sich auf eine Microsoft Graph-Ressource, auf die die Berechtigung Zugriff gewährt. 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 verfügbar gemachten 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 wird möglicherweise nicht explizit deklariert. 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, sie 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.
Ressourcenspezifische Zustimmungsberechtigungen (RSC)
RSC ist ein Autorisierungsframework, das bereichsbezogenen Zugriff auf die Daten gewährt, 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, empfängt die App Objekte dieses Typs, jedoch mit eingeschränkten Informationen. Beispielsweise können nur der Objekttyp und die ID zurückgegeben werden, und andere Eigenschaften werden als nullangegeben. Die App empfängt vollständige Informationen für die Objekttypen, für die sie leseberechtigungen hat.
Dieses Prinzip gilt für alle Beziehungen vom Typ directoryObject . 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 und um weitere Informationen für die Mitglieder der Gruppe zurückzugeben, benötigt die App die folgenden zusätzlichen Berechtigungen:
- Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Benutzer sind, ist User.ReadBasic.All die Berechtigung mit den geringsten Berechtigungen.
- Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Gruppen sind, ist GroupMember.Read.All die Berechtigung mit den geringsten Berechtigungen.
- Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Geräte sind, ist Device.Read.All die Berechtigung mit den geringsten Berechtigungen.
- Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, die Dienstprinzipale sind, ist Application.Read.All die Berechtigung mit den geringsten Berechtigungen.
- Gemäß dem Prinzip der geringsten Rechte sollten Sie es vorziehen, die oben genannten Berechtigungen entsprechend Ihrer Anwendung zu verwenden. Als Alternative zu den einzelnen Berechtigungen auf Ressourcenebene kann der App jedoch 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 macht präzise Berechtigungen verfügbar, die es einer App ermöglichen, nur die Berechtigungen anzufordern, die sie zum Funktionieren benötigt. Mit präzisen Berechtigungen können Sie das Prinzip der geringsten Rechte anwenden, wenn Sie einer App Berechtigungen zuweisen und gewähren. Erteilen Sie der App die erforderliche Mindestberechtigung für den Vorgang.
Betrachten Sie die folgenden Beispiele:
- Eine App muss 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.
Einer Anwendung mehr Berechtigungen zu gewähren, als sie benötigt, ist eine schlechte Sicherheitspraxis. Dadurch erhöht sich die Gefährdung der App gegenüber nicht autorisiertem und unbeabsichtigtem Zugriff auf Daten oder Vorgänge. Darüber hinaus kann das Anfordern von mehr Berechtigungen als erforderlich dazu führen, dass Benutzer einer App nicht zustimmen, 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. Verwenden Sie diese Berechtigungen mit Vorsicht und nur bei Bedarf. 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 Infrastructure-as-Code-Frameworks 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.