获取访问资源的授权
本文帮助开发人员了解在获取应用程序的资源访问权限时如何最好地确保零信任。 要访问受保护资源（例如电子邮件或日历数据），应用程序需要获取资源所有者的授权。 资源所有者可以同意或拒绝应用的请求。 当资源所有者授予同意时，应用会收到访问令牌；当资源所有者拒绝访问时，应用不会收到访问令牌。
概念评审
可以使用 Microsoft 标识平台对应用程序进行身份验证和授权，以及管理权限和同意。 让我们先了解一些概念：
身份验证（有时缩写为 AuthN）是证明所声明标识准确的流程。 Microsoft 标识平台使用 OpenID Connect 协议来处理身份验证。 授权（有时缩写为 AuthZ）授予经过身份验证的参与方执行某些操作的权限。 它指定经过身份验证的参与方可以访问哪些数据。 Microsoft 标识平台使用 OAuth2.0 协议来处理授权。 授权选项包括访问控制列表 (ACL)、基于角色的访问控制和属性访问控制 (ABAC)。 身份验证通常是授权因素。
委托访问权限（代表已登录的用户执行操作）或直接访问权限（仅以应用程序自身的身份执行操作）允许应用程序访问数据。 委托访问需要委托的权限（也称为范围）；客户端和用户必须单独获得授权才能发出请求。 直接访问权限可能需要应用程序权限（也称为应用角色）；向应用程序授予应用角色时，此类角色可称为应用程序权限。
委托的权限与委托访问一起使用，允许应用程序代表用户执行操作，仅访问用户可以访问的内容。 应用程序权限与直接访问一起使用，允许应用程序访问与该权限关联的任何数据。 只有服务主体的管理员和所有者才能同意应用程序权限。
同意是应用程序接收权限的方式。 用户或管理员授权应用程序访问受保护的资源。 同意提示列出了应用程序需要的权限以及发布者信息。
预授权是资源应用程序所有者授予客户端应用访问权限的方式。 他们可以在 Azure 门户中或使用 PowerShell 和 Microsoft Graph 等 API 来执行此操作。 他们可以授予资源权限，而无需向用户显示预授权权限集的同意提示。
委托的权限与应用程序权限之间的差异
应用程序在两种模式下工作：当用户存在时（委托的权限）和没有用户时（应用程序权限）。 当应用程序前面有用户时，将强制你代表该用户执行操作；不应代表应用程序本身执行操作。 当用户指导应用程序时，你将充当该用户的代理人。 你将获得代表令牌标识的用户执行操作的权限。
服务类型应用程序（后台任务、守护程序、服务器到服务器进程）没有可识别自己或键入密码的用户。 它们需要应用程序权限来代表自身（代表服务应用程序）。
零信任应用程序授权最佳做法
连接到应用程序中的现有用户以及调用的资源时，授权方法将身份验证用作组件。 当应用程序代表用户执行操作时，我们不信任调用应用程序告诉我们的用户身份，也不会让应用程序决定用户身份。 Microsoft Entra ID 验证并直接在令牌中提供有关用户的信息。
当需要允许应用程序调用 API 或授权应用程序以使应用程序可以访问资源时，新式授权方案可以通过权限和同意框架要求授权。 参考应用程序属性的安全最佳做法，其中包括重定向 URI、访问令牌（用于隐式流）、证书和机密、应用程序 ID URI 和应用程序所有权。
后续步骤
- 自定义令牌介绍了可以在 Microsoft Entra 令牌中接收的信息。 它说明如何自定义令牌以提高灵活性和控制，同时提高最低特权下的应用程序零信任安全性。
- 在令牌中配置组声明和应用角色介绍了如何使用应用角色定义来配置应用，以及如何将安全组分配给应用角色。 这些方法有助于提高灵活性和控制，同时提高最低特权下的应用程序零信任安全性。
- 制定委托权限策略可帮助你实施有关在应用程序中管理权限的最佳方法，并使用零信任原则进行开发。
- 制定应用程序权限策略可帮助你确定应用程序权限凭据管理方法。
- 在没有用户时提供应用程序标识凭据解释了为何 Azure 资源的托管标识是适用于 Azure 上的服务（无用户应用程序）的最佳客户端凭据实践。
- 授权最佳做法可帮助你为应用程序实现最佳授权、权限和同意模型。
- 在应用程序开发生命周期中使用零信任身份和访问管理开发最佳做法来创建安全应用程序。
- 使用零信任标识方法构建应用从零信任身份和访问管理开发最佳做法文章继续，以帮助你在软件开发生命周期 (SDLC) 中使用零信任标识方法。