通过

使用 Microsoft Entra ID 授权应用程序、资源和工作负载

  • 项目

在本文中，我们将讨论当个人与应用程序交互并指示应用程序时，当应用程序编程接口 (API) 对用户执行操作时，这种情况下的授权。 我们还介绍了应用程序或服务何时独立工作。 这是关于独立软件开发人员 (ISV) 如何为 Microsoft Entra ID 生成和优化其应用程序的系列文章中的第四篇文章。 在此系列中，可以了解有关以下主题的详细信息：

应用程序中的授权

在本部分中，我们将介绍个人与应用程序交互并指导应用程序的场景。 资源 (API) 中的授权部分介绍了当用户需要授权访问资源时，API 如何执行授权，但 Microsoft Entra ID 不执行最终授权。 工作负荷中的授权部分介绍应用程序或服务独立工作的方案。

当应用程序需要访问用户的资源时，需要以下授权。

  • 应用程序必须具有访问当前用户特定资源内特定操作的授权。
  • 用户必须具有在当前条件下访问资源的授权。
  • 用户必须具有访问资源的授权。

授权过程首先使用 OAuth 2.0 从 Microsoft Entra ID 请求访问令牌的应用程序，以访问用户的特定资源中的特定操作。 在委派访问中，应用充当用户的委托。

对于开发人员，资源可以是 Microsoft Graph、Azure 存储或自己的 API 等 API。 但是，大多数 API 都有各种操作，例如读取和写入。 当应用程序仅从 API 读取时，应用应仅具有读取操作的授权。 此方法可保护应用程序免受入侵，并用于比开发人员预期的更多访问权限。 当开发人员仅授权其所需的操作时，开发人员遵循最低特权原则。

若要指定应用程序所需的特定 API 中的哪些特定操作，开发人员使用 OAuth 2.0 请求的范围参数。 API 设计器发布应用程序作为 API 应用注册的一部分可以请求的范围。 例如，Power BI 服务范围包括以下内容。

Power BI 服务范围 Operations
https://analysis.chinacloudapi.cn/powerbi/api/Capacity.Read.All 应用可以查看登录用户有权访问的所有 Power BI Premium 和 Power BI Embedded 容量。
https://analysis.chinacloudapi.cn/powerbi/api/Capacity.ReadWrite.All 应用可以查看和编辑登录用户有权访问的所有 Power BI Premium 和 Power BI Embedded 容量。

如果应用程序仅读取容量，应用将请求 https://analysis.chinacloudapi.cn/powerbi/api/Capacity.Read.All 范围。 如果应用程序编辑容量，应用将请求 https://analysis.chinacloudapi.cn/powerbi/api/Capacity.ReadWrite.All 范围。

范围包含 API 的标识和操作的标识。 在 https://analysis.chinacloudapi.cn/powerbi/api/Capacity.ReadWrite.All 范围内，API 为 https://analysis.chinacloudapi.cn/powerbi/api。 操作是 Capacity.ReadWrite.All。 鉴于 Microsoft Graph API 的广泛覆盖范围和受欢迎程度，开发人员可以在没有作用域的 API 组件的情况下请求 Microsoft Graph 的范围。 例如，Microsoft Graph 定义了应用程序可以使用 Files.Read 请求的 https://microsoftgraph.chinacloudapi.cn/Files.Read 范围，而不是使用完整范围名称。

若要完成第一次授权，应用程序必须具有访问当前用户特定资源内特定操作的授权，Microsoft Entra ID 必须先对当前用户进行身份验证。 单一登录 (SSO) 可以满足此身份验证，或者可能需要新的用户交互。

在 Microsoft Entra ID 确定用户后，它会检查用户是否为请求的范围授权了应用程序。 此过程称为授权同意。 如果用户已授予许可，授权过程可以继续。 管理员同意允许管理员用户同意自行和整个组织。 Microsoft Entra ID 检查应用程序是否具有管理员对范围的同意。 如果已授予授权，则授权过程将继续执行。

在范围设计期间，API 设计器可以指定只有管理员才能同意的范围。 需要管理员同意的范围表示 API 设计器认为更敏感、更强大或广泛地牵连到足以让非管理员用户无权授予应用程序的操作。

虽然 API 设计器在哪些范围需要管理员同意方面有第一个发言权，但他们没有最终决定权。 当 API 设计器指定范围需要管理员同意时，范围始终需要管理员同意。 对于 API 设计器未指定为需要管理员同意的范围，租户管理员可以要求管理员同意，或基于风险的分步同意可以确定管理员同意要求。 开发人员无法预测令牌请求是否需要管理员同意。 但是，此限制不会影响所需的代码。 同意拒绝只是令牌请求拒绝的许多原因之一。 应用程序必须始终正常处理不接收令牌。

如果用户或管理员尚未授予许可，则用户会看到同意提示，如以下示例所示。

用户同意提示的屏幕截图。

管理员用户同意提示可能允许他们代表组织选择同意，为租户中的所有用户授予同意，如以下示例所示。

管理员同意提示的屏幕截图。

应用程序控制用户同意提示的时间。 Microsoft Entra ID 支持静态同意：当应用程序使用 .default 范围时，应用请求在应用注册中声明的所有权限。 通过静态同意，你的应用会提前请求它可能需要的所有权限。

静态同意可能会阻止用户和管理员批准应用的访问请求。 同意请求过程的最佳做法是在应用程序启动时动态请求应用程序中基线功能所需的权限，并在需要时请求更多范围。 以增量方式请求更多范围，因为应用程序执行需要这些范围的操作。 此方法为用户提供了更好地了解与功能计时相关的其他权限。 对于每个 API 访问令牌，Microsoft Entra ID 包括以前授予应用程序的所有范围，而不仅仅是请求中的范围。

例如，应用程序可以请求 https://microsoftgraph.chinacloudapi.cn/user.read 在应用程序启动时登录用户并访问用户配置文件。 稍后，用户选择“保存到 OneDrive”，应用程序请求 https://microsoftgraph.chinacloudapi.cn/files.readwrite，将文件写入用户的 OneDrive。 由于用户看到应用请求写入其 OneDrive 的原因，因此用户授予权限，应用会将文件保存到用户的 OneDrive。 然后，用户关闭应用。 下次应用启动时，它会请求 https://microsoftgraph.chinacloudapi.cn/user.read。 Microsoft Entra ID 返回带有 https://microsoftgraph.chinacloudapi.cn/user.read 和 https://microsoftgraph.chinacloudapi.cn/files.readwrite 范围的访问令牌。 https://microsoftgraph.chinacloudapi.cn/files.readwrite 范围的令牌请求不需要用户授予许可。 Microsoft 身份验证库中的令牌缓存 (MSAL) 会自动根据授予的权限处理缓存令牌。 在此示例中，在应用重启后，调用 MSAL 以获取具有 https://microsoftgraph.chinacloudapi.cn/files.readwrite 范围的令牌，返回从应用对 https://microsoftgraph.chinacloudapi.cn/user.read 范围的初始请求中缓存的令牌。 不需要对 Microsoft Entra ID 进行另一次调用。

在应用程序注册期间，动态和增量许可不需要声明的权限。 但是，强烈建议应用程序声明应用程序在应用注册中可能需要的任何权限，以支持静态同意。 管理员可以使用 Microsoft Graph PowerShell 或 Microsoft Graph API 在 Microsoft Entra 管理中心中授予管理员同意。

为了向应用程序授予管理员同意，Microsoft Entra 管理中心通过请求同意应用的 .default 范围来使用静态同意。 如果开发人员未在应用注册中声明权限，管理员无法在 Microsoft Entra 管理中心向需要权限的应用授予管理员同意。

Microsoft Entra ID 客户可以使用条件访问策略来保护资源 (API) 和基于浏览器的应用程序。 默认情况下，管理员不能将条件访问策略应用于本机应用身份验证。 租户管理员可以针对所有云应用（旧称‘所有云应用’）或使用自定义安全属性，利用条件访问策略以本机应用为目标。 即使有其他目标，策略强制实施也不包括访问 Microsoft Graph 或 Azure AD Graph 的某些应用。

除非以下方案适用，否则应用程序通常不需要条件访问的特殊代码。

  • 执行代理流的应用
  • 访问多个服务或资源的应用
  • 使用 MSAL.js 的单页应用
  • 调用资源的 Web 应用

如果应用实现上述任一方案，请查看 Microsoft Entra 条件访问的开发人员指南。

免费 Microsoft Entra ID 租户无法使用条件访问（请参阅许可要求。 贵公司的生产租户可能具有所需的许可。 在使用生产租户进行测试之前，请评估这些条件。 有创建测试租户的指导。

默认情况下，条件访问策略适用于应用程序以及应用在应用级别访问的资源。 IT 管理员可以将应用级策略应用到任何应用，而无需开发人员参与。 某些应用程序和方案需要更精细的粒度。 例如，财务应用可能需要多重身份验证，以供典型使用。 但是，超过指定金额的事务可能需要托管设备。 开发人员可以通过实现条件访问身份验证上下文，使 IT 管理员能够将分步条件访问策略分配给应用程序的不同区域。 条件访问身份验证上下文的开发人员指南是这些功能的一个很好的参考。

默认情况下，Microsoft Entra ID 颁发在设定时间内有效的访问令牌。 应用程序必须绝不假定生存期长度。 它们必须使用 Microsoft Entra ID 使用访问令牌返回的 expires_in 参数。 MSAL 会自动处理此方案。 在访问令牌的生存期内，用户在授权时有权访问资源。

条件更改与策略更改强制实施时间之间的滞后时间可能会影响管理员和用户。 例如，当用户失去设备时，IT 管理员可以撤销用户的会话。 但是，丢失设备上的应用可以继续访问用户的 Microsoft Graph，直到令牌过期。

如果无法在 MSAL 上生成，应用必须使用 OAuth 2.0 从 Microsoft Entra ID 请求访问令牌。 Microsoft 标识平台和 OAuth 2.0 授权代码流提供了 Microsoft Entra ID 支持的流的实现详细信息。

资源中的授权 (API)

当应用程序需要访问用户的资源，但只涵盖前两个时，应用中的授权部分引入了三个必需的授权。 用户必须具有访问资源的授权，但 Microsoft Entra ID 不执行最终授权。 资源 (API) 执行授权。

API 在为用户执行操作时必须强制实施两个授权：

  • API 必须授权应用调用 API。 检查访问令牌的 scp （范围）声明是否包含所需的范围。
  • API 必须授权用户访问特定资源。 令牌中的 oid （对象 ID）和 sub （使用者）声明表示用户标识。

建议使用 oid 和 sub 声明进行授权。

Microsoft Entra ID 实现成对 sub 声明，因此 sub 声明是请求应用的唯一用户标识符。 使用不同应用的同一用户具有不同的 sub 声明。 对于所有应用，oid 声明对所有用户是保持不变的。

应用程序向 Microsoft Entra ID 在 http 请求授权标头中作为持有者令牌保护的 API 提供所需的访问令牌。 API 必须完全验证收到的令牌，因为令牌不直接来自 Microsoft Entra ID。 在令牌验证之前，将调用应用视为不可信。 访问令牌引用和声明验证参考文章提供有关验证 Microsoft Entra ID 访问令牌的详细信息。

Microsoft Entra ID 发布 API 用于验证令牌签名的公钥。 这些密钥定期以及需要公钥滚动更新的任何时候滚动更新。 应用程序必须绝不假定公钥滚动更新的设置计划。 Microsoft 标识平台中的签名密钥滚动更新介绍了如何正确处理公钥滚动更新。

建议使用维护良好的库来执行令牌验证。 如果要在 ASP.NET 或 ASP.NET Core 上生成 Web 应用或 API，请使用 Microsoft.Identity.Web 来处理令牌验证。 受保护的 Web API 操作方法文章介绍了如何使用 Microsoft.Identity.Web 来保护 API。

API 有时需要调用其他 API。 当应用适用于用户时，API 会收到包含当前用户标识的委托访问令牌。 重要的是，API 仅信任来自 Microsoft Entra ID 的已验证令牌，以确定当前用户的标识。 此方法可防止应用程序泄露，以便用户模拟其他用户，并访问其他用户的资源。 对于同一保护，当一个 API 调用另一个 API 时，请使用代表 OAuth 流获取访问令牌，以为其调用 API 的用户调用 API。 生成调用 Web API 的 Web API 为 API 提供为当前应用用户调用其他 API 的步骤。

除了委派访问之外，API 可能需要支持应用程序并独立操作，而无需当前用户。 Microsoft Entra ID 将这些应用程序称为工作负载。 若要强制实施工作负荷授权，API 不使用 scp （范围）声明。 相反，API 使用 roles 声明来验证工作负荷是否具有所需的同意。 API 负责强制工作负荷有权访问资源。

工作负荷中的授权

工作负荷是独立工作且没有当前用户的应用程序。 与应用程序中授权部分中所述的委托访问一样，仅限应用的访问需要多个授权：

  • 应用程序必须具有访问特定资源内特定操作的授权。
  • 应用程序必须具有在当前条件下访问资源的授权。
  • 应用程序必须具有访问资源的授权。

此过程从请求具有 .default 范围的访问令牌（如 https://microsoftgraph.chinacloudapi.cn/.default）的工作负荷开始。 与委派访问（应用程序可以动态和增量请求范围）不同，工作负荷必须始终使用静态同意和 .default 范围。

API 设计器通过将角色添加到 API 的应用注册来创建其 API 的应用权限。 这些角色具有允许的应用程序的成员类型，该类型允许将角色分配给工作负荷。 在 Microsoft Entra 管理中心或 Microsoft Graph 中将角色分配给工作负荷。 在 Microsoft Entra 管理中心中，必须先获得已分配角色的管理员同意，然后才能运行工作负荷。

默认情况下，应用权限授权工作负荷访问资源的所有实例。 例如，https://microsoftgraph.chinacloudapi.cn/user.read.all 授权工作负荷访问租户中每个用户的完整用户配置文件。 IT 管理员通常不愿意授予这些广泛的权限。

对于访问 Microsoft Graph 的工作负荷，请使用以下方法来限制应用程序权限：

与具有用户的应用程序不同，工作负荷会自行向 Microsoft Entra ID 进行身份验证。

对于在 Azure 中运行的工作负荷，用于对自身进行身份验证的工作负荷的最佳方法是 Azure 资源的托管标识。 托管标识功能无需管理工作负荷的凭据。 没有可访问的凭据。 Microsoft Entra ID 完全管理凭据。 如果没有要管理的凭据，任何凭据都面临泄露的风险。

随着安全性的提高，托管标识也会提高复原能力。 托管标识使用来自 Microsoft Entra ID 的长期访问令牌和信息在令牌过期之前获取新的令牌。 托管标识使用区域终结点，可通过合并服务依赖项来帮助防止区域外故障。 区域终结点有助于将流量保持在地理区域中。 例如，如果你的 Azure 资源位于 ChinaNorth2，则所有流量都保留在 ChinaNorth2。

如果工作负荷未在 Azure 中运行，则工作负荷必须使用 OAuth 2.0 客户端凭据流进行身份验证。

Microsoft Entra ID 支持以下客户端凭据类型：

  • 证书。 工作负荷通过使用私钥签署断言来证明他们拥有私钥。 私钥不会传输到 Microsoft Entra ID。 仅发送断言。 建议使用证书而不是客户端机密，因为它们更安全，而且管理得更好。
  • 联合凭据。 工作负荷标识联合使未在 Azure 上运行的工作负荷能够使用来自其他标识提供者、GitHub Actions 或 Kubernetes 群集的标识。 工作负荷请求令牌的方式与证书凭据的联合凭据相同。 区别在于断言（已签名的 JSON Web 令牌）来自联合标识提供者。
  • 客户端密码。 客户端机密有时称为应用程序密码，它是一个字符串值，工作负荷可以使用该值来标识自身。 机密的文本值从工作负荷发送到用于令牌的 POST 请求的 Microsoft Entra ID。 客户端机密的安全性低于证书或工作负荷标识联合。 如果工作负荷使用机密，请遵循以下管理机密的最佳做法。

除了 Microsoft Entra ID，Microsoft Entra 产品系列还包括 Microsoft Entra 工作负荷 ID。 Microsoft Entra 工作负荷 ID 具有以下高级功能来增强工作负荷安全性。

  • 访问评审可将评审委派给适当的人员，专注于最重要的特权角色。
  • 应用运行状况建议建议如何解决应用程序组合中的标识卫生差距，并提高租户安全性和复原能力。

后续步骤