本文可帮助你以开发人员身份设计 应用程序权限策略 ，以提供 最低权限。 在继续操作之前，请参阅 API 保护 文章，了解注册、权限和访问权限的最佳做法。
让我们看看受Microsoft标识平台保护的 API 如何使用 Microsoft标识许可框架。 我们使用 Microsoft 图形 API 作为示例，因为它可以充分利用Microsoft标识平台许可框架。
权限名称的命名约定
Microsoft Graph 团队为权限名称创建了命名约定，以便更轻松地将权限连接到权限启用的资源访问。 Microsoft Graph 权限名称 遵循简单的 resource.operation.constraint 模式。 这两个主要操作是 Read 和 ReadWrite （包括更新和删除）。
约束元素会影响应用在目录中具有的访问程度。 Microsoft Graph 支持以下约束：
- 所有权限授予您的应用对目录中指定类型的所有资源进行操作的权限。
- 共享 授予应用权限，以便对其他用户与已登录用户分享的资源进行操作。
- AppFolder 授予应用读取和写入 OneDrive 中专用文件夹中文件的权限。 此约束仅在 Files 权限 对象上公开，并且仅对Microsoft帐户有效。
- 如果指定 “无约束”，则应用只能对已登录用户拥有的资源执行操作。
针对特定资源的访问和操作
让我们看看 Microsoft Graph 中用户对象的一些权限或范围，了解Microsoft API 设计器如何针对特定资源启用特定访问和操作：
| 许可 | 显示字符串 | 说明 |
|---|---|---|
User.Read |
登录和读取用户个人资料 | 允许用户登录到应用，并允许应用读取已登录用户的个人资料。 它还允许应用读取已登录用户的基本公司信息。 |
User.ReadWrite |
对用户个人资料的读写权限 | 允许应用读取已登录用户的完整个人资料。 它还允许应用代表其更新已登录用户的个人资料信息。 |
User.Read 并 User.ReadWrite 存在（而不是单个权限，如 User.Access 不存在的权限），以便应用程序可以遵循 最低权限的零信任 原则。 如果开发人员没有更新用户资料的需求和代码，则应用不会要求 User.ReadWrite。 因此，不良参与者无法破坏应用程序并使用它来更改数据。
请注意， User.Read 不只是授予应用程序对用户对象的访问权限。 每个权限表示特定的操作范围。 开发人员和管理员必须阅读权限说明，以准确了解任何特定权限启用的内容。
User.Read 除了允许读取当前用户的完整配置文件外，还允许应用程序访问 Microsoft Graph 中 Organizations 对象的基本信息。
让我们看看另一个权限：
| 许可 | 显示字符串 | 说明 |
|---|---|---|
User.ReadBasic.All |
读取所有用户的基本个人资料 | 允许应用在具备权限的情况下，代表登录用户读取组织中其他用户的一系列基本个人资料属性。 包括显示名称、名字和姓氏、电子邮件地址、打开的扩展插件和照片。 允许应用读取已登录用户的完整个人资料。 |
User.ReadBasic.All的操作范围包括User.Read所有的功能。 此外，还可以访问其他组织用户的显示名称、名字和姓氏、电子邮件地址、照片和开放扩展插件。 特定的操作范围使应用程序能够拥有良好的人员选取器 UI，并且是 API 设计器使用权限启用特定操作范围的示例。
让我们看看对 Microsoft Graph 用户对象的更多权限：
| 许可 | 显示字符串 | 说明 |
|---|---|---|
User.Read.All |
读取所有用户的完整个人资料 | 允许应用程序代表登录用户读取组织中其他用户的完整个人信息属性、报表和管理者信息。 |
User.ReadWrite.All |
读取和写入所有用户的完整个人资料 | 允许应用代表登录用户读取和写入组织中其他用户的完整个人资料属性、报告和经理信息。 还允许应用代表已登录用户创建和删除用户并重置用户密码。 |
与User.Read和User.ReadWrite相似，User.Read.All和User.ReadWrite.All是不同的权限，使应用程序能够遵循最低特权零信任原则。
User.Read.All 很有趣，因为组织中的每个用户都有此功能（例如打开 Outlook、向上和向下报告链）。 作为个人，你可以看到组织中所有其他用户的完整用户配置文件。 但是，Microsoft图形 API 设计器决定只有管理员才允许应用程序执行相同的操作，因为 User.Read.All 包括租户的组织层次结构。 如果一个不良参与者访问了此信息，他们可能会发动有针对性的网络钓鱼攻击，其中钓鱼电子邮件来自某个人的经理或其经理。
User.ReadWrite.All 是一个强大的操作范围。 具有此权限的应用程序可以更新甚至删除租户中的每个用户。 作为 委派权限，当用户在应用前面时，应用只能执行当前用户可以执行的操作。 无论应用的权限如何，常规用户都无法更新或删除其他用户。 但是，当租户管理员使用应用时，他们可以执行这些操作。 当你决定授予或拒绝此权限时，请从租户管理员用户的角度来评估你的应用。
需要管理员同意的权限
鉴于User.Read.All和User.ReadWrite.All的功能，Microsoft Graph API 设计者将这些权限指定为需要管理员同意。 让我们向权限表添加一个 管理员？ 列，以指示权限何时需要管理员同意：
| 许可 | 显示字符串 | 说明 | 管理员？ |
|---|---|---|---|
User.Read |
登录和读取用户个人资料 | 允许用户登录到应用，并允许应用读取已登录用户的个人资料。 它还允许应用读取已登录用户的基本公司信息。 | 否 |
User.ReadWrite |
对用户个人资料的读写权限 | 允许应用读取已登录用户的完整个人资料。 它还允许应用代表其更新已登录用户的个人资料信息。 | 否 |
User.ReadBasic.All |
读取所有用户的基本个人资料 | 允许应用在具备权限的情况下，代表登录用户读取组织中其他用户的一系列基本个人资料属性。 包括显示名称、名字和姓氏、电子邮件地址、打开的扩展插件和照片。 允许应用读取已登录用户的完整个人资料。 | 否 |
User.Read.All |
读取所有用户的完整个人资料 | 允许应用程序代表登录用户读取组织中其他用户的完整个人信息属性、报表和管理者信息。 | 是的 |
User.ReadWrite.All |
读取和写入所有用户的完整个人资料 | 允许应用代表登录用户读取和写入组织中其他用户的完整个人资料属性、报告和经理信息。 还允许应用代表已登录用户创建和删除用户并重置用户密码。 | 是的 |
如请求需要管理许可的权限文章中所述，租户管理员可以推翻要求，并指定在其租户中的任何或所有应用程序权限需要管理员同意。 将应用设计为在未收到请求令牌时正常处理。 缺乏同意是你的应用可能不会收到令牌的许多原因之一。
后续步骤
- 从另一个 API 调用 API 可帮助你在一个 API 需要调用另一个 API 时确保零信任，并在应用程序代表用户工作时安全地开发应用程序。
- 获取访问资源的授权 可帮助你了解如何在获取应用程序的资源访问权限时最好地确保零信任。
- 自定义令牌介绍了可以在 Microsoft Entra 令牌中接收的信息。 本文介绍如何自定义令牌以提高灵活性和控制，同时提高应用程序零信任安全性（最低特权）。
- 在令牌中配置组声明和应用角色介绍了如何使用应用角色定义来配置应用，以及如何将安全组分配给应用角色。 这些方法有助于提高灵活性和控制，同时提高应用程序零信任安全性（最低特权）。
- 描述需要管理许可的请求权限 描述在应用程序权限需要管理许可时的权限和许可体验。
- 本 快速入门：使用Microsoft标识平台保护 Web API，下载并运行代码示例，演示如何保护 ASP.NET Web API。
- 在 本教程 - 在 Azure API 管理中转换和保护 API，了解如何配置通用策略以隐藏 API HTTP 响应正文中的技术堆栈信息和原始 URL。
- 授权最佳做法可帮助你为应用程序实现最佳授权、权限和同意模型。