SharePoint 和 OneDrive 具有一个长期建立的权限模型，该模型并不完全适合范围模型。 例如，提供对租户中单个列表的 ReadWrite 访问权限的全局范围不存在。 相反，所选范围支持这些方案。 最初，Sites.Selected 的存在用于限制应用程序对单个网站集的访问。 现在，还支持列表、列表项、文件夹和文件，并且所有选定的范围现在都支持委托和应用程序模式。
注意
由于范围命名要求的发展，较新的范围作为完整元 *.SelectedOperations.Selected组列出。 此格式和 Sites.Selected 格式之间没有功能差异。
Scopes
下表列出了“所选”权限范围。
| Scopes | 说明 |
|---|---|
| Sites.Selected | 在网站集级别管理应用程序访问权限，提供对特定网站集的访问权限 |
| Lists.SelectedOperations.Selected | 在列表级别管理应用程序访问权限，提供对特定列表的访问权限 |
| ListItems.SelectedOperations.Selected | 在文件、列表项或文件夹级别管理应用程序访问权限，提供对一个或多个列表项的访问权限 |
| Files.SelectedOperations.Selected | 在文件或库文件夹级别管理应用程序访问权限，提供对一个或多个文件的访问权限 |
所选范围如何使用 SharePoint 和 OneDrive 权限
当管理员同意为应用程序选择范围时，他们会将资源权限的管理委托给工作负载中该资源的所有者。 对于其他范围（如 Files.Read.All），一旦同意范围，应用程序就可以访问它表示的资源。 所选范围需要显式分配操作;同意 Lists.SelectedOperations.Selected 的应用程序最初将无权访问。
所选范围需要一系列步骤才能工作，这为管理员提供了多种控制方式。 以下示例使用 Lists.SelectedOperations.Selected 范围，但步骤适用于所有 *。所选范围。
- 应用程序必须在 Entra ID 中获得许可，才能具有应用程序或委托
Lists.SelectedOperations.Selected的范围。 - 必须使用特定角色通过调用
POST /sites/{siteid}/lists/{listid}/permissions向 应用程序授予对列表的权限。 - 应用程序必须获取有效的令牌，该令牌包含
Lists.SelectedOperations.Selected对权限列表的调用范围。
如果错过了这三个步骤中的任何一个步骤，则应用程序无权访问。 管理员两个控制点：
- 通过调用
DELETE /sites/{siteid}/lists/{listid}/permissions/{id}删除对特定列表的权限，这将删除对该应用程序列表的访问权限。 -
Lists.SelectedOperations.Selected撤销 Entra ID 中的范围许可，这会阻止应用程序访问以前向其授予权限的任何列表。
基于此，你可以同意应用程序在 Lists.SelectedOperations.Selected Entra ID 中的范围，但不授予对任何列表的权限 - 这意味着应用程序没有访问权限。 同样，你可以为任何应用程序调用 POST /sites/{siteid}/lists/{listid}/permissions ，但令牌中未显示适当的范围，则应用程序无权访问。 必须完成这三个步骤才能确保预期的访问。 这也适用于其他 *。所选范围及其各自的级别。
注意
将应用程序权限分配给列表、列表项、文件夹或文件会中断对分配的资源的继承，因此请注意解决方案设计中 唯一权限的服务限制 。 网站集级别的权限不会中断继承，因为这是权限继承的根。
显示了为 网站设置权限的示例; 列表、 列表项、 文件或 文件夹的逻辑类似。
文件和 listItems 作用域之间有什么区别？
在 SharePoint 中，所有文件都是列表项，但所有列表项不是文件。 因此，携带范围 ListItems.SelectedOperations.Selected 的应用程序可以访问所有列表项和文件，并对其允许的角色进行操作。 具有 Files.SelectedOperations.Selected 的应用程序只能对文件 (文档库中) 列表项或其他标记为包含文档的列表项进行操作。 这模拟了目前存在的 Files.Read.All 和 Files.ReadWrite.All 行为，但与单个文件隔离。 此行为不会根据 Microsoft Graph 路径而更改，例如 和 /drives/{driveid}/items/{itemid}/sites/{siteid}/lists/{listid}/items/{itemid};相反，要访问的目标控制行为。
角色
下表列出了可分配给给定资源的应用程序的四个角色。
| Role | 说明 |
|---|---|
| 阅读 | 读取资源的元数据和内容。 |
| 写入 | 读取和修改资源的元数据和内容。 |
| 所有者 | 表示所有者角色。 |
| fullcontrol | 表示对资源的完全控制。 |
请求
POST https://graph.microsoft.com/v1.0/sites/{siteId}/permissions
Content-Type: application/json
{
"roles": ["write"],
"grantedTo": {
"application": {
"id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e"
}
}
}
请求标头
| 名称 | 说明 |
|---|---|
| Authorization | 持有者 {token}。 必填。 详细了解 身份验证和授权。 |
| Content-Type | application/json. 必需。 |
响应
HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "1",
"@deprecated.GrantedToIdentities": "GrantedToIdentities has been deprecated. Refer to GrantedToIdentitiesV2",
"roles": ["write"],
"grantedToIdentities": [{
"application": {
"id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
"displayName": "Contoso Time Manager App"
}
}],
"grantedToIdentitiesV2": [{
"application": {
"id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
"displayName": "Contoso Time Manager App"
}
}]
}
有关演示如何管理权限的示例，请参阅/permissions站点、列表、listItem 和 driveItem 的 API 主题。
管理权限需要哪些权限？
权限要求因级别而异。 在所有委托的情况下，当前用户还需要足够的权限通过调用 API 来管理访问权限。 下表包括范围和范围以及分配给父资源的角色。 例如，如果你有 Sites.Selected 作用域和 FullControl 角色 (Sites.Selected+FullControl) ，则可以管理该网站集中的资源。
| 资源 | 所需的资源权限 | 注释 |
|---|---|---|
| 网站 | Sites.FullControl.All | 由于可以使用 Sites.Selected 向网站集授予完全控制权限，因此此要求必然很高。 |
| list | Sites.FullControl.All、Sites.Selected+FullControl、Sites.Selected+Owner | |
| listItem | Sites.FullControl.All、Sites.Selected+FullControl、Sites.Selected+Owner、Lists.SelectedOperations.Selected+FullControl、Lists.SelectedOperations.Selected+Owner | |
| file | Sites.FullControl.All、Sites.Selected+FullControl、Sites.Selected+Owner、Lists.SelectedOperations.Selected+FullControl、Lists.SelectedOperations.Selected+Owner |
如何计算访问权限
有两种类型的令牌：仅限应用程序令牌和委托令牌。 仅限应用程序方案没有用户存在，并且被视为高风险。 通过委托，应用程序永远不能超过当前用户的现有权限，并且在许多情况下可以被视为风险较低。 委托是首选（如果可能），但这两种模式都可用于满足你的需求。
存储应用程序 ID、资源 ID 和角色的元组。 因此，[应用程序] 具有对 [资源] 的 [角色] 访问权限。 通过 API 创建权限时，可以指定应用程序和角色，并且解析的路径会提供资源。 例如，应用程序 Z 对 /sites/dev/lists/list1 处的列表具有读取访问权限。
若要计算访问权限，请使用令牌中提供的值大致遵循此流：
查看应用程序或委托) (令牌类型。
在资源或安全分层父级 (继承) 查找提供的应用程序 ID 的应用程序记录。
出现以下情况之一：
- 对于应用程序访问，如果找到应用程序的记录，并且角色允许请求的操作 (读取项、更新列表) ，则授予访问权限。
- 在委托方案中，将计算应用程序和用户权限，然后相交，这意味着应用程序永远不会超过用户的权限，并且用户永远不能超过 (通过应用程序) 同意的应用程序权限。
同意行为说明
以下说明适用于许可行为：
- 应用程序可以有多个选定的同意，这些同意可以在租户的不同级别应用。
- 一旦撤销范围，应用程序访问权限就会丢失。 如果应用程序具有 Lists.* 和 Sites.*，并且被授予对网站集和该网站集中的特定列表的访问权限，然后撤销 Sites.* 同意，则应用程序将保持对通过 Lists.* consent 和上一次调用 授予其特定访问权限的列表的访问权限
list/permissions。 - 如果应用程序通过调用
list/permissions具有对 列表的权限，并且通过调用DELETE lists/permissions/id删除了访问权限，则它将失去对该列表和该列表中所有项的访问权限，而不管这些列表项上设置的任何显式权限。 稍后可以根据需要重新授予特定项权限。 - 更高级别的范围（如 Sites.*）可用于授予特定于文件的权限，但较低范围永远无法提供对更高级别资源的访问权限。 这允许应用程序在特定级别拥有访问权限。
- 同意是一个外部概念，由 OneDrive 和 SharePoint 通过提供的令牌使用，并且遵循令牌中提供的任何范围。