当应用程序直接访问资源（如 Microsoft Graph）时，其访问权限并不局限于任何单个用户可用的文件或操作。 应用程序直接使用自己的标识调用 API，并且具有管理员权限的用户或应用必须授权它访问资源。 此方案是仅限应用的访问。
何时应使用仅限应用的访问？
在大多数情况下，仅应用访问比委托访问更广泛且功能更强大，因此应仅在需要时使用仅限应用的访问权限。 在以下情况下，这通常是正确的选择：
- 应用需要以自动化方式运行，无需用户输入。 例如，检查来自某些联系人的电子邮件并发送自动响应的每日脚本。
- 应用需要访问属于多个不同用户的资源。 例如，备份或数据丢失防护应用可能需要从许多不同的聊天频道检索消息，每个频道都有不同的参与者。
- 你发现自己很想在本地存储凭据，并允许应用以用户或管理员的身份登录。
相比之下，切勿使用仅限应用的访问，用户通常会登录以管理自己的资源。 这些类型的方案必须使用委派访问权限才能获得最低特权。
授权应用进行仅限应用的调用
若要进行仅限应用的调用，需要为客户端应用分配适当的应用角色。 应用角色也称为仅限应用的权限。 它们是应用角色，因为它们仅在定义角色的资源应用中授予访问权限。
例如，若要读取在组织中创建的所有团队的列表，需要为应用程序分配 Microsoft Graph Team.ReadBasic.All 应用角色。 当 Microsoft Graph 是资源应用时，此应用角色授予读取此数据的能力。 此分配不会将客户端应用分配到可能允许它通过其他服务查看此数据的 Teams 角色。
作为开发人员，你需要配置所有必需的仅限应用权限，也称为应用注册的应用角色。 您可以通过 Azure 门户或 Microsoft Graph 配置应用仅请求的应用权限。 仅限应用的访问权限不支持动态同意，因此无法在运行时请求单个权限或权限集。
配置应用所需的所有权限后，它必须获得 管理员同意 才能访问资源。 例如，只有至少具有特权角色管理员角色的用户才能为 Microsoft Graph API 授予仅限应用的权限（应用角色）。 具有其他管理员角色（如应用管理员和云应用程序管理员）的用户能够向其他资源授予仅限应用的权限。
管理员用户可以使用 Azure 门户或通过 Microsoft Graph API 以编程方式创建授权来授予仅限应用的权限。 你还可以从应用内提示交互式同意，但此选项并不理想，因为仅限应用的访问权限不需要用户。
拥有 Microsoft 帐户（如 Outlook.com 或 Xbox Live 帐户）的使用者用户永远无法授权仅限应用的访问权限。
始终遵循最小权限原则：永远不要请求应用不需要的角色。 如果应用遭到入侵，此原则将有助于遏制安全风险，并使管理员更方便地授予应用访问权限。 例如，如果仅限应用的访问需要识别用户而不读取其详细个人资料信息，则应请求限制更多的 Microsoft Graph User.ReadBasic.All 应用角色而不是User.Read.All 。
为资源服务设计和发布应用角色
如果要在公开其他客户端调用 API 的 Microsoft Entra ID 上生成服务，则可能希望支持使用应用角色（仅限应用权限）进行自动访问。 可以在 Microsoft Entra 管理中心的应用注册的“应用角色”部分定义应用程序的应用角色。 有关如何创建应用角色的详细信息，请参阅声明应用的角色。
公开应用角色供其他人使用时，请向要分配应用角色的管理员提供方案的明确说明。 应用角色通常应尽可能窄并支持特定的功能方案，因为仅限应用的访问权限不受用户权限的限制。 避免公开向服务包含的所有 API 和资源授予完全read或完全 read/write访问权限的单个角色。
注意
还可以将应用角色 (仅限应用的权限) 配置为支持分配给用户和组。 请确保针对预期的访问方案正确配置应用角色。 如果打算将 API 的应用角色用于仅应用访问，请在创建应用角色时选择应用作为唯一允许的成员类型。
仅限应用的权限如何运作？
关于仅限应用的访问，需要记住的最重要的一点是，调用应用代表其自身并以自己的标识执行操作。 没有用户交互。 如果将应用分配给某个资源的给定应用角色，则该应用将完全不受约束地访问该应用角色管理的所有资源和作。
将应用分配到一个或多个应用角色（仅限应用权限）后，可以使用 客户端凭据流 或任何其他受支持的身份验证流从 Microsoft Entra ID 请求仅限应用的令牌。 分配的角色将添加到roles应用的访问令牌的声明中。
在某些情况下，应用程序标识可能会确定是否授予访问权限，这与委托调用中的用户权限类似。 例如，Application.ReadWrite.OwnedBy应用角色授予应用管理应用本身拥有的服务主体的能力。
仅限应用的访问示例 - 通过 Microsoft Graph 自动发送电子邮件通知
以下示例演示了一个真实的自动化方案。
每当驻留在 Windows 文件共享中的部门报告文件夹注册新文档时，Alice 都希望通过电子邮件通知团队。 Alice 创建一个计划任务，该任务运行 PowerShell 脚本来检查文件夹并查找新文件。 然后，该脚本使用受资源 API Microsoft Graph 保护的邮箱发送电子邮件。
脚本无需任何用户交互即可运行，因此授权系统仅检查应用授权。 Exchange Online 检查进行调用的客户端是否由管理员授予应用程序权限（应用角色 Mail.Send ）。 如果未向应用授予Mail.Send，则 Exchange Online 请求失败。
| POST /users/{id}/{userPrincipalName}/sendMail | 客户端应用授予 Mail.Send | 客户端应用未授予 Mail.Send |
|---|---|---|
| 该脚本使用 Alice 的邮箱发送电子邮件。 | 200 – 已授予访问权限。 管理员允许应用以任何用户身份发送邮件。 | 403 - 未授权。 管理员不允许此客户端发送电子邮件。 |
| 该脚本创建用于发送电子邮件的专用邮箱。 | 200 – 已授予访问权限。 管理员允许应用以任何用户身份发送邮件。 | 403 - 未授权。 管理员不允许此客户端发送电子邮件。 |
给出的示例是应用授权的简单说明。 Exchange Online 服务支持许多其他访问方案，例如将应用权限限制为特定的 Exchange Online 邮箱。