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. Bevor die Microsoft Identity Platform Ihre App für den Zugriff auf Daten über Microsoft Graph autorisieren kann, müssen Sie der App die erforderlichen Berechtigungen gewähren.
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 sind rollenbasierte Zugriffssteuerungssysteme (Role-Based Access Control, RBAC) wie Microsoft Entra RBAC. In einigen Fällen erfordert der Zugriff auf Daten über Microsoft Graph-APIs möglicherweise sowohl Microsoft Graph-Berechtigungen als auch RBAC-Berechtigungen.
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 Nur-App-Zugriff ruft die App Microsoft Graph mit ihrer eigenen Identität auf, ohne dass ein Benutzer angemeldet ist.
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. Diese Berechtigungen ermöglichen es der Anwendung, im Namen eines angemeldeten Benutzers zu handeln. Die Anwendung kann jedoch auf nichts zugreifen, auf das der angemeldete Benutzer nicht zugreifen konnte.
Beispielsweise erhält eine Anwendung die Files. Read.All delegierte Berechtigungen im Namen von Tom, einem Benutzer. Die Anwendung kann nur alle Dateien in der organization lesen, auf die Tom bereits zugreifen kann. Tom kann möglicherweise auf die Dateien zugreifen, da er über eine der folgenden Arten verfügt:
- Tom hat die Dateien erstellt oder besitzt diese.
- Die Dateien wurden direkt für 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 einer App, die im Namen eines Benutzers handeln soll, durch die Microsoft Graph-Berechtigungen, die der App erteilt wurden, und durch die eigenen Berechtigungen des Benutzers bestimmt.
In einem Szenario mit delegiertem Zugriff kann eine App Benutzern erlauben, sich mit ihren persönlichen Microsoft-Konten anzumelden, z. B. Outlook.com-, Geschäfts-, Schul- oder Unikonten oder beiden Kontotypen. 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 App-Rollen genannt, funktionieren im Nur-App-Zugriffsszenario, ohne dass ein angemeldeter Benutzer anwesend ist. Die Anwendung kann auf alle Daten zugreifen, denen die Berechtigung zugeordnet ist. Beispielsweise hat eine Anwendung, der die Files erteilt hat. Die Anwendungsberechtigung "Read.All" kann jede Datei in der organization lesen.
Mit der Anwendungsberechtigung User.ReadWrite.All kann eine Anwendung viele der von Microsoft Graph unterstützten beschreibbaren Benutzereigenschaften aktualisieren, auch für Benutzer, denen privilegierte Administratorrollen zugewiesen sind.
Anwendungsberechtigungen sind hoch privilegiert, da sie Anwendungen den Zugriff auf und die Änderung von Ressourcen ermöglichen, ohne dass ein angemeldeter Benutzer erforderlich ist. Aus Sicht der geringsten Rechte ist das Modell der delegierten Berechtigungen der empfohlene Ansatz, wenn es die Anforderungen der Anwendung erfüllt.
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 das Microsoft Entra Admin Center installiert wird. Nur Administratoren mit privilegierten Rollen und globale Administratoren können Anwendungsberechtigungen erteilen.
Neben der Zuweisung von Microsoft Graph-Anwendungsberechtigungen können einer App die erforderlichen Berechtigungen auch durch eine der folgenden Bedingungen erteilt 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? |
Die Verfügbarkeit der Benutzerzustimmung hängt auch von den App-Zustimmungsrichtlinien Ihres Mandanten ab. Auch wenn die Zustimmung des Administrators standardmäßig nicht für eine Berechtigung erforderlich ist, können die Richtlinien Ihrer organization die Zustimmung des Benutzers einschränken |
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.
Bewährte Methoden zum Auswählen von Berechtigungstypen für die Connector-Agent-Registrierung
Microsoft Graph Connector-Agents werden als Hintergrunddienste ausgeführt und erfordern Microsoft Graph-Anwendungsberechtigungen.
Delegierte Berechtigungen werden für die Connector-Agent-Registrierung nicht unterstützt und verursachen Registrierungsfehler, selbst wenn die Berechtigungen ordnungsgemäß konfiguriert erscheinen.
Fordern Sie die am wenigsten privilegierten Anwendungsberechtigungen an, die für Ihr Connectorszenario erforderlich sind, und stellen Sie sicher, dass die mandantenweite Administratorzustimmung erteilt wird.
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} |
Verweist 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-Operationen, 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 ist 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, diese jedoch nicht zu ändern oder zu löschen.
- Member.Read.Hidden – Ermöglicht der App, ausgeblendete 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 einen bereichsbezogenen Zugriff auf die von einer Ressource verfügbar gemachten Daten gewährt. Über RSC kann ein autorisierter Benutzer einer App Zugriff auf die Daten einer bestimmten Instance eines Ressourcentyps gewähren. Sie müssen nicht App-Zugriff auf jede Instance des Ressourcentyps im gesamten Mandanten gewähren.
RSC-Berechtigungen sind auch für die Zustimmung verfügbar und werden nur von einer Teilmenge der Funktionen unterstützt, die über Microsoft Graph verfügbar sind, z. B. Teams, Chats und Nachrichten. Weitere Informationen finden Sie unter RSC-Berechtigungen und 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 begrenzten Informationen. Beispielsweise können nur der Objekttyp und die ID zurückgegeben werden, während andere Eigenschaften als nullangegeben werden. Die App erhält vollständige Informationen über die Objekttypen, für die sie über Leseberechtigungen verfügt.
Dieses Prinzip gilt für alle Beziehungen vom Typ directoryObject . Beispiele umfassen , /groups/{id}/members/users/{id}/memberOf, und me/ownedObjects.
Eine Gruppe kann beispielsweise Benutzer, Gruppen, Anwendungen, Dienstprinzipale, Geräte und Kontakte als Mitglieder haben. Einer App wird die Berechtigung GroupMember.Read.All mit den geringsten Berechtigungen zum Auflisten von Gruppenmitgliedern erteilt. 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, bei denen es sich um Gruppen handelt, ist GroupMember.Read.All die Berechtigung mit den geringsten Berechtigungen.
- Um die grundlegenden Eigenschaften der Mitglieder einer Gruppe zu lesen, bei denen es sich um Geräte handelt, 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.
- Verwenden Sie gemäß dem Prinzip der geringsten Rechte die oben genannten Berechtigungen entsprechend Ihrer Anwendung. Als Alternative zu den einzelnen Berechtigungen auf Ressourcenebene weisen Sie der App jedoch die Berechtigung Directory.Read.All zu, um alle Eigenschaften für alle Mitgliedstypen 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 präzise Berechtigungen zur Verfügung, die es einer App ermöglichen, nur die Berechtigungen anzufordern, die sie zum Funktionieren benötigt. Mit granularen Berechtigungen können Sie beim Zuweisen und Erteilen von Berechtigungen für eine App das Prinzip der geringsten Rechte anwenden. Erteilen Sie der App die für den Vorgang erforderliche Mindestberechtigung.
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 Anwendungsberechtigung GroupMember.Read.All , die am wenigsten privilegierte Berechtigung 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 erteilen, als sie benötigt, ist eine schlechte Sicherheitspraxis. Dies erhöht die Anfälligkeit der App für nicht autorisierten und unbeabsichtigten 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 Akzeptanz 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 eine größere Bandbreite an Daten oder Vorgängen als andere. Verwenden Sie diese 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. Directory.ReadWrite.All steht an zweiter Stelle in der Berechtigungsbewertung. Directory.Read.All ist die höchste privilegierte schreibgeschützte Berechtigung für Microsoft Entra ID-Ressourcen. Verwenden Sie diese Berechtigungen mit Vorsicht und nur bei Bedarf. Verwenden Sie stattdessen immer Berechtigungen mit niedrigeren Berechtigungen.
In der API-Referenzdokumentation zu Microsoft Entra ID-Ressourcen können einige dieser höherprivilegierten Berechtigungen möglicherweise absichtlich aus der Tabelle der Berechtigungen ausgeschlossen werden, die für den Zugriff auf die API unterstützt werden.
Darüber hinaus ist die Rolle des globalen Administrators die höchste privilegierte integrierte Rolle in Microsoft Entra ID. In der API-Referenzdokumentation wird diese Rolle absichtlich aus der Liste der Rollen ausgeschlossen, die den Zugriff auf die API unterstützen, zugunsten von Rollen mit geringeren Berechtigungen.
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 |
Hinweis
Für Microsoft Entra-Agent-ID sind einige Microsoft Graph-Berechtigungen mit hohem Risiko global für Agenten blockiert und können Agentidentitäten nicht gewährt werden.
Wenn Sie einen blockierten delegierten Microsoft Graph-Berechtigungsbereich oder eine App-Rolle in die resourceAccess Sammlung eines requiredResourceAccess Eintrags aufnehmen, wird die Anforderung mit einer HTTP-Antwort 400 Bad Request und einem Fehler abgelehnt, der angibt, dass die Berechtigung blockiert ist und Agentidentitäten nicht erteilt werden kann.
Eine Liste der blockierten Microsoft Graph-Berechtigungen für Agenten finden Sie unter Für Agenten blockierte Microsoft Graph-Berechtigungen.
Abrufen von Berechtigungs-IDs über Microsoft Graph
Zum Festlegen von Berechtigungen mithilfe der Azure CLI, PowerShell oder Infrastruktur als Codeframeworks 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.