获取访问资源的授权

本文将帮助开发人员了解如何在获取应用程序的资源访问权限时最好地确保零信任。 要访问受保护资源（例如电子邮件或日历数据），应用程序需要获取资源所有者的授权。 资源所有者可以同意或拒绝应用的请求。 当资源所有者同意时，你的应用将收到访问令牌；当资源所有者拒绝访问时，你的应用不会收到访问令牌。

概念评审

可以使用 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) 中使用零信任标识方法。