在Microsoft标识平台中，了解权限和同意对于开发需要访问受保护资源的安全应用程序至关重要。 本文概述了与权限和同意相关的基本概念和方案，帮助应用程序开发人员从用户和管理员请求必要的授权。 通过了解这些概念，可以确保应用程序仅请求所需的访问权限，促进信任和安全性。
若要访问受保护的资源（如电子邮件或日历数据），应用程序需要资源所有者的授权。 资源所有者可以同意或拒绝应用的请求。 了解这些基本概念有助于构建更安全且可信的应用程序，这些应用程序仅请求用户和管理员提供所需的访问权限。
访问场景
作为应用程序开发人员，必须确定应用程序如何访问数据。 应用程序可以使用代表已登录用户执行操作的委托访问权限，也可以使用仅以应用程序自己的身份执行操作的“仅应用”访问权限。
委托访问权限（代表用户访问）
在此访问方案中，用户已登录到客户端应用程序。 客户端应用程序代表用户访问资源。 委托访问权限需要委托的权限。 客户端和用户都必须单独获得发出请求的授权。 有关委托访问方案的详细信息，请参阅委托访问方案。
对于客户端应用，必须授予正确的委托的权限。 委托的权限也可以称作范围。 范围是给定资源的权限，表示客户端应用程序可以代表用户访问的内容。 有关范围的详细信息，请参阅范围和权限。
对于用户，授权依赖于授予用户访问资源的权限。 例如，可以授权用户通过 Microsoft Entra 基于角色的访问控制 (RBAC) 访问目录资源，或通过 Exchange Online RBAC 访问邮件和日历资源。 有关应用程序的 RBAC 的详细信息，请参阅 适用于应用程序的 RBAC。
“仅应用”访问（没有用户参与的访问）
在此访问方案中，应用程序以自己的身份执行操作，且没有任何用户登录。 在自动化和备份等方案中会使用应用程序访问权限。 此方案包括作为后台服务或守护程序运行的应用。 如果不希望特定的用户登录，或者所需数据的访问权限范围不能限定为单个用户，则很适合使用此方案。 有关仅应用访问方案的详细信息，请参阅 仅限应用的访问权限。
仅限应用的访问使用应用角色而不是委托范围。 通过同意来授予时，应用角色也可能被称为应用程序权限。 必须向客户端应用授予其所调用的资源应用的适当应用程序权限。 一旦获得授权，客户端应用就可以访问所请求的数据。 若要详细了解如何将应用角色分配给客户端应用程序，请参阅向应用程序分配应用角色。
权限的类型
委托的权限在委托访问方案中使用。 这些权限允许应用程序代表用户执行操作。 应用程序无法访问已登录用户无法访问的任何内容。
例如，假设一个应用程序代表用户被授予Files.Read.All 委派权限。 应用程序只能读取用户可以亲自访问的文件。
应用程序权限（也称为应用角色）用于仅限应用的访问方案，无需登录用户在场。 应用程序能够访问与该权限关联的任何数据。
例如，授予 Microsoft Graph API 应用程序权限 Files.Read.All 的应用程序可以使用 Microsoft Graph 读取租户中的任何文件。 通常，只有 API 服务主体的管理员或所有者才能同意该 API 公开的应用程序权限。
委托的权限和应用程序权限的比较
| 权限类型 | 委托的权限 | 应用程序权限 |
|---|---|---|
| 应用类型 | Web/移动/单页应用 (SPA) | Web/守护程序 |
| 访问上下文 | 代表用户获取访问权限 | 在不是用户的情况下获取访问权限 |
| 谁可以许可 | - 用户可以同意使用其数据 - 管理员可以同意所有用户 |
只有管理员可以同意 |
| 同意方法 | - 静态：在应用注册时配置的列表 - 动态：在登录时请求单个权限 |
- 仅静态：应用注册时配置的列表 |
| 其他名称 | - 范围 - OAuth2 权限范围 |
- 应用角色 - 仅限应用的权限 |
| 同意结果（特定于 Microsoft Graph） | OAuth2PermissionGrant | appRoleAssignment |
同意
为应用程序授予权限的一种方式是通过同意。 同意是用户或管理员授权应用程序访问受保护资源的过程。 例如，当用户首次尝试登录到某个应用程序时，该应用程序可以请求查看用户个人资料和读取用户邮箱内容的权限。 用户可以通过同意提示来查看应用正在请求的权限列表。 用户可能会看到同意提示的其他方案包括：
- 撤销以前授予的同意时。
- 应用程序被编码为在用户登录期间专门提示用户同意。
- 当应用程序使用动态许可在运行时根据需要请求新权限时。
同意提示的重要详细信息是应用程序所需的权限列表和发布者信息。 有关管理员和最终用户的同意提示和同意体验的详细信息，请参阅 应用程序同意体验。
用户同意
当用户尝试登录到应用程序时，会发生用户同意流程。 用户提供其登录凭据，这些凭据经过检查以确定是否已授予许可。 如果不存在用户或管理员同意所需权限的以往记录，则系统会向用户显示同意提示，并询问用户是否为应用程序授予请求的权限。 管理员可能需要代表用户授予同意。
管理员同意
根据所需的权限，某些应用程序可能需要管理员来授予同意。 例如，应用程序权限和许多高特权委托的权限只能由管理员同意。
管理员可为自己或整个组织授予同意。 有关用户和管理员同意的详细信息，请参阅用户和管理员同意概述。
如果未授予同意，并且请求了其中一个高特权权限，则会提示管理员同意身份验证请求。
包含自定义应用程序范围的权限请求不被视为高权限，因此不需要管理员同意。
预身份验证
预授权允许资源应用程序所有者授予权限，而无需用户查看预授权的相同权限集的同意提示。 这样，预授权的应用程序不会要求用户同意权限。 资源所有者可以在 Azure 门户中或使用 PowerShell 和 API（如 Microsoft Graph）预授权客户端应用。
其他授权系统
同意框架只是授权应用程序或用户访问受保护资源的一种方式。 管理员应了解可能允许访问敏感信息的其他授权系统。 Microsoft中各种授权系统的示例包括Microsoft Entra 内置角色、Azure RBAC、Exchange RBAC和Teams 资源特定权限。