在 Microsoft 标识平台授权应用访问 Microsoft 云中的数据之前，必须向应用授予所需的权限。 同样，在 Microsoft 标识平台授权应用通过 Microsoft Graph 访问数据之前，必须先向应用授予所需的权限。
授予应用通过 Microsoft Graph 访问和处理数据所需的权限的一种方法是向其分配 Microsoft Graph 权限。 另一种方法是通过基于角色的访问控制 (RBAC) 系统，如 Microsoft Entra RBAC。 在某些情况下，通过 Microsoft Graph API 访问数据可能需要 Microsoft Graph 权限和 RBAC 权限。
本文介绍 Microsoft Graph 权限并提供使用这些权限的指南。 若要查看 Microsoft Graph 公开的权限的完整列表，请参阅 Microsoft Graph 权限参考。
要了解有关权限如何工作的更多信息，请观看以下视频。
权限类型
Microsoft Graph 支持 两种访问方案： 委派访问 和 仅应用访问。 在委派访问中，应用代表登录用户调用 Microsoft Graph。 在仅应用访问中，应用使用自己的标识调用 Microsoft Graph，而无需登录用户。
为了支持这些访问方案，Microsoft Graph 公开 了委派的权限 和 应用程序权限。
委派权限
委托的权限（也称为 范围）在委派的访问方案中起作用。 这些权限允许应用程序代表登录用户执行操作。 但是，应用程序无法访问登录用户无法访问的任何内容。
例如，应用程序获取 Files。Read.All 代表 Tom（用户）委派的权限。 应用程序只能读取 Tom 已可以访问的组织中的所有文件。 Tom 可能能够访问这些文件，因为他通过以下方式之一具有权限：
- Tom 创建或拥有这些文件。
- 这些文件直接与 Tom 共享，或通过团队或组成员资格间接共享。
- Tom 已通过受支持的 RBAC 系统获得权限。
因此，在委派方案中，应用必须代表用户执行操作的权限由应用被授予的 Microsoft Graph 权限 和 用户自己的权限决定。
在委派访问方案中，应用可能允许用户使用其个人Microsoft帐户（如 Outlook.com 帐户、工作或学校帐户或这两种帐户类型登录）。 所有委托的权限都对工作或学校帐户有效，但并非所有权限都对个人 Microsoft 帐户有效。 使用 Microsoft Graph 权限引用 确定对个人 Microsoft 帐户有效的委派权限。
当用户登录应用时，他们或管理员（在某些情况下）有机会同意委派的权限。 如果用户同意，应用则可以在用户权限范围内访问资源和 API。
注意
通过 Microsoft Entra 内置角色授予的权限不会限制应用仅调用 Microsoft Graph API。
应用程序权限
应用程序权限（也称为 应用角色）在仅应用访问场景中有效，无需登录用户。 应用程序可以访问与权限关联 的任何 数据。 例如，应用程序授予了 Files。Read.All 应用程序权限可以读取组织中的任何文件。
借助 User.ReadWrite.All 应用程序权限，应用程序可以更新 Microsoft Graph 支持的许多可写用户属性，包括分配了特权管理员角色的用户。
应用程序权限具有很高的特权，因为它们允许应用程序访问和修改资源，而无需登录用户。 从最低权限的角度来看，只要满足应用程序的要求，就推荐使用委派权限模型。
对于在没有登录用户的情况下访问资源和 API 的应用，在租户中安装应用时或通过 Microsoft Entra 管理中心安装应用时，管理员同意应用程序权限。 只有特权角色管理员和全局管理员才能同意应用程序权限。
除了分配 Microsoft Graph 应用程序权限外，还可能通过以下条件之一向应用授予所需的权限：
- 何时为应用分配了要管理的资源的所有权。
- 通过 RBAC 系统或自定义管理角色为应用分配权限时。
注意
通过 Microsoft Entra 内置角色授予的权限不会限制应用仅调用 Microsoft Graph API。
委派权限和应用程序权限的比较
| 类别 | 委派权限 | 应用程序权限 |
|---|---|---|
| 应用类型 | Web 应用 / 移动 / 单页应用 (SPA) | Web/守护程序 |
| 访问上下文 | 代表用户获取访问权限 | 不代表用户获取访问权限 |
| 谁可以同意 |
用户同意可用性还取决于租户的 应用同意策略。 即使默认情况下，权限不需要管理员同意，组织的策略仍可能限制用户同意 |
只有管理员才能同意 |
| 其他名称 | ||
| 同意结果 | oAuth2PermissionGrant 对象 | appRoleAssignment 对象 |
| 支持的 signInAudience 类型 | AzureADMyOrg AzureADMultleOrgs AzureADandPersonalMicrosoftAccount PersonalMicrosoftAccount |
AzureADMyOrg AzureADMultleOrgs AzureADandPersonalMicrosoftAccount |
下图演示了在委派与仅应用访问方案中的应用权限。
为连接器代理注册选择权限类型的最佳实践
Microsoft Graph 连接器代理作为后台服务运行，需要 Microsoft Graph 应用程序权限。
连接器代理注册不支持委托的权限，并导致注册失败，即使权限配置正确也是如此。
请求连接器方案所需的 最小特权应用程序权限 ，并确保授予 租户范围的管理员同意 。
权限命名模式
Microsoft Graph 公开粒度权限，可帮助控制应用对用户、组和邮件等 Microsoft Graph 资源的访问权限。 这些权限遵循命名模式：
{resource}。{operation}.{constraint}
| 值 | 说明 | 示例 |
|---|---|---|
{resource} |
指权限授予访问权限的 Microsoft Graph 资源。 例如， user 资源。 |
User、 或 ApplicationGroup |
{operation} |
指允许对资源公开的数据执行的 Microsoft 图形 API 操作。 例如， Read 仅用于读取操作，或 ReadWrite 用于读取、创建、更新和删除操作。 |
Read、、ReadBasic、ReadWrite、CreateManage、或Migrate |
{constraint} |
确定应用在目录中具有的潜在访问范围。 此值可能未显式声明。 未声明时，默认约束仅限于登录用户拥有的数据。 |
All, AppFolder, OwnedBy, Selected, Shared, Hidden |
示例：
- User.Read - 允许应用读取有关已登录用户的信息。
- Application.ReadWrite.All - 允许应用管理租户中的所有应用程序。
- Application.ReadWrite.OwnedBy - 允许应用仅管理它创建或拥有的应用程序。
- Group.Create - 允许应用程序创建新组，但不能修改或删除它们。
- Member.Read.Hidden - 允许应用读取隐藏的成员身份。
有关 Microsoft Graph 公开的权限的完整列表，请参阅 Microsoft Graph 权限参考。
(RSC) 权限的特定于资源的许可
RSC 是一种授权框架，可授予对资源公开的数据进行特定范围的访问。 通过 RSC，授权用户可以向应用授予对资源类型的特定实例的数据的访问权限。 他们不需要向应用授予对整个租户中资源类型的每个实例的访问权限。
RSC 权限也适用于同意，并且仅受 Microsoft Graph 提供的部分功能（如 Teams、聊天和消息）支持。 有关详细信息，请参阅 RSC 权限和可用 RSC 权限的完整列表。
为不可访问的成员对象返回有限的信息
容器对象（例如组）支持各种类型的成员（例如用户和设备）。 当具有适当权限的应用程序查询容器对象的成员身份时，它会收到响应 200 OK 和对象集合。 但是，如果应用没有读取容器中特定对象类型的权限，则该应用将接收该类型的对象，但包含有限的信息。 例如，可能仅返回对象类型和 ID，而其他属性表示为 null。 应用接收其有权读取的对象类型的完整信息。
此原则适用于 directoryObject 类型的所有关系。 示例包括 /groups/{id}/members、 和 /users/{id}/memberOfme/ownedObjects。
例如，组可以将用户、组、应用程序、服务主体、设备和联系人作为成员。 向应用授予 GroupMember.Read.All 列表 组成员的最小特权权限。 在响应对象中，仅为返回的所有成员填充 id 和 @odata.type 属性。 其他属性表示为 null。 对于此 API，并且若要为组成员返回更多信息，应用需要以下额外权限：
- 若要读取组成员（即用户）的基本属性， User.ReadBasic.All 是最低特权权限。
- 若要读取组成员（即组）的基本属性， GroupMember.Read.All 是最低特权权限。
- 若要读取组成员（即设备）的基本属性， Device.Read.All 是最低特权权限。
- 若要读取作为服务主体的组成员的基本属性， Application.Read.All 是最低特权权限。
- 根据最小特权原则，根据应用程序使用上述权限;但是，作为单个资源级权限的替代方法，请向应用分配 Directory.Read.All 权限来读取 所有成员类型的所有属性。
示例
请求
GET https://graph.microsoft.com/v1.0/groups/{id}/members
响应
以下对象是一个响应示例：
{
"@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
}
]
}
使用 Microsoft Graph 权限的最佳做法
Microsoft Graph 公开粒度权限，允许应用仅请求正常运行所需的权限。 粒度权限允许你在向应用分配和授予权限时应用 最小权限 原则。 授予应用执行操作所需的最小权限。
请考虑下面的示例：
- 应用需要读取已登录用户的个人资料信息。 应用只需要 User.Read 权限，这是访问已登录用户信息的最小特权。 授予应用 User.ReadWrite 权限会使其具有过高权限，因为应用不需要更新用户的配置文件。
- 应用需要在没有登录用户的情况下读取租户中的组。 应用只需要 GroupMember.Read.All 应用程序权限，这是在没有登录用户的情况下读取租户中的组的最小特权权限。
- 应用需要读取或写入已登录用户的日历。 该应用管理动态作业，并从用户的 Outlook 日历同步，使应用保持最新，以便为用户安排作业。 即使 获取 用户的日历数据需要 Calendars.Read，但使用计划作业更新日历 需要 更高特权的权限 Calendars.ReadWrite。 在这种情况下，应用应请求 Calendars.ReadWrite。
授予应用程序比其需要更多的权限是一种糟糕的安全做法。 它增加了应用程序对数据或操作的未经授权和意外访问的风险。 此外，请求超过必要的权限可能会导致用户不同意应用，从而影响应用的采用和使用。
向应用分配和授予 Microsoft Graph 权限时应用最低特权原则。 有关详细信息，请参阅 使用最小特权原则增强安全性和 构建 通过权限和同意保护身份的应用。
谨慎使用的权限
某些 Microsoft Graph 权限授予的访问权限比其他权限更广泛的数据或操作。 请谨慎使用这些权限。 例如，Directory.AccessAsUser.All 权限是最高特权委派权限，可授予对 Microsoft Entra ID 中的几乎所有 API 操作的访问权限。 Directory.ReadWrite.All 权限在特权排名中排名第二。 Directory.Read.All 是 Microsoft Entra ID 资源的最高特权只读权限。 必要时请谨慎使用这些权限。 请始终改用特权较低的选项权限。
在与 Microsoft Entra ID 资源相关的 API 参考文档中，可能会有意将其中一些更高特权的权限排除在支持访问 API 的权限表之外。
此外，全局管理员角色是 Microsoft Entra ID 中特权最高的内置角色。 在 API 参考文档中，有意将此角色从支持访问 API 的角色列表中排除，以支持特权较低的角色。
每个应用请求的权限限制
Microsoft Entra ID 限制客户端应用可以请求和同意的权限数。 这些限制取决于signInAudience应用清单中显示的应用值。
| signInAudience | 允许的用户 | 应用可以请求的最大权限 | 应用可以请求的最大 Microsoft Graph 权限 | 单个请求中可同意的最大权限 |
|---|---|---|---|---|
| AzureADMyOrg | 注册应用的组织中的用户 | 400 | 400 | 大约 155 个委派权限和大约 300 个应用程序权限 |
| AzureADMultleOrgs | 来自任何 Microsoft Entra 组织的用户 | 400 | 400 | 大约 155 个委派权限和大约 300 个应用程序权限 |
| PersonalMicrosoftAccount | 消费者用户（如 Outlook.com 或 Live.com 帐户） | 30 | 30 | 30 |
| AzureADandPersonalMicrosoftAccount | 使用者用户和来自任何 Microsoft Entra 组织的用户 | 30 | 30 | 30 |
注意
对于 Microsoft Entra 智能体 ID，某些高风险 Microsoft Graph 权限会全局阻止代理使用，并且无法授予代理标识。
如果在条目集合requiredResourceAccess中resourceAccess包含阻止的 Microsoft Graph 委派权限范围或应用角色，则请求将被拒绝，并显示 HTTP 400 Bad Request 响应和错误，指示权限已被阻止且无法授予代理标识。
有关阻止的代理 Microsoft Graph 权限的列表，请参阅阻止代理 的 Microsoft Graph 权限。
通过 Microsoft Graph 检索权限 ID
若要使用 Azure CLI、PowerShell 或基础结构即代码框架设置权限，可能需要要使用的权限的标识符，而不是名称。 权限引用列出了所有 Microsoft Graph 权限的 ID。 或者，可以通过 Microsoft Graph 中的 获取服务主体 API 以编程方式读取有关 Microsoft Graph 权限的信息。 以下示例显示了一个请求。
GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')?$select=id,appId,displayName,appRoles,oauth2PermissionScopes,resourceSpecificApplicationPermissions
appRoles、oauth2PermissionScopes 和 resourceSpecificApplicationPermissions 对象分别存储应用程序、委派和资源特定的许可权限。