通过

管理零信任的令牌

  • 项目

在零信任应用程序开发中，必须明确定义应用程序的意图及其资源访问要求。 应用应仅请求按预期运行所需的访问权限。 本文可帮助开发人员利用 ID 令牌、访问令牌和安全令牌在应用程序中构建安全性，应用程序可以从 Microsoft 标识平台接收这些令牌。

确保应用程序遵循最低特权零信任原则，并防止损害意图的使用方式。 使用实时和恰好足够的访问权限 (JIT/JEA)、基于风险的自适应策略和数据保护，来限制用户访问。 将应用的敏感部分和功能强大的部分分开，仅允许授权用户访问这些区域。 限制可以使用应用程序的用户及其在应用中拥有的功能。

在应用程序管理从 Microsoft 身份验证平台接收的 ID 令牌的过程中生成最低特权。 使用 ID 令牌中的信息，你可以验证用户是否是其声称的身份。 用户或其组织可能会指定身份验证条件，例如提供 MFA，使用托管设备，或者位于正确的位置。

使客户能够轻松管理应用的授权。 减少用户设置开销和对手动过程的需求。 自动用户设置允许 IT 管理员在目标标识存储中自动创建、维护和删除用户标识。 客户可以通过 Microsoft Entra ID 中的“应用设置”或“HR 驱动的设置”，基于对用户和组所做的更改实现自动化。

在应用中使用令牌声明

将 ID 令牌中提供的声明用于应用程序内部的用户体验、作为数据库中的键以及提供客户端应用程序访问权限。 此 ID 令牌是 OpenID Connect (OIDC) 向 OAuth 2.0 发出的核心扩展。 应用可以同时接收 ID 令牌和访问令牌，也可以只接受其一。

在安全令牌授权的标准模式中，发放的 ID 令牌允许应用程序接收有关用户的信息。 不要将 ID 令牌用作访问资源的授权过程。 ID 令牌由授权服务器发放，其中包含的声明提供以下用户信息。

  • 受众 (aud) 声明是应用的客户端 ID。 仅接受 API 客户端 ID 的令牌。
  • tid 声明是发放令牌的租户的 ID。 oid 声明是唯一标识用户的不可变值。 需要将数据与用户关联时，将 tid 和 oid 声明的唯一组合用作密钥。 可以使用这些声明值，将数据重新连接到 Microsoft Entra ID 中的用户 ID。
  • sub 声明是唯一标识用户的不可变值。 使用者声明对于应用程序也是唯一的。 如果使用 sub 声明将数据与用户相关联，则无法从数据中将其与 Microsoft Entra ID 中的用户连接。

应用可以使用 openid 范围，从 Microsoft 标识平台请求 ID 令牌。 OIDC 标准规定了 openid 范围，以及 ID 令牌的格式和内容。 OIDC 指定这些范围：

  • 使用 openid 范围登录用户，并向 ID 令牌添加 sub 声明。 这些范围提供对应用和用户唯一的用户 ID，并且调用 UserInfo 终结点。
  • 该 email 范围包含用户电子邮件地址的 email 声明添加到 ID 令牌。
  • 该 profile 范围将具有用户（名称、用户名）的基本配置文件属性的声明添加到 ID 令牌中。
  • 即使用户不存在，offline_access 范围也允许应用访问用户数据。

Microsoft 身份验证库 (MSAL) 始终将 openid、电子邮件和 profile 范围添加到每个令牌请求。 因此，MSAL 始终在每次调用 AcquireTokenSilent 或 AcquireTokenInteractive 时,返回 ID 令牌和访问令牌。 MSAL 始终请求 offline_access 范围。 即使请求应用未指定 offline_access 范围，Microsoft 标识平台也始终返回 offline_access 范围。

Microsoft 使用 OAuth2 标准发放访问令牌。 OAuth2 标准表示你收到令牌，但它未指定令牌格式或令牌中所需的内容。 当应用程序需要访问 Microsoft Entra ID 保护的资源时，应使用定义的资源范围。

例如，Microsoft Graph 定义了授权应用程序访问当前用户的完整用户配置文件和租户名称的 User.Read 范围。 Microsoft Graph 定义该 API 中提供的全部功能的权限。

授权后，Microsoft 标识平台会向应用程序返回访问令牌。 调用资源时，应用会提供此令牌，作为对 API 的 HTTP 请求的授权标头的一部分。

管理令牌生存期

使用 Microsoft Entra ID 成功完成身份验证后，应用程序可为用户创建会话。 用户会话管理会影响用户需要重新认证的频率。 它的作用是让经过显式验证的用户在适当的时间内，以适当的特权使用应用程序，这一点至关重要。 会话生存期必须基于 ID 令牌中的 exp 声明。 exp 声明是 ID 令牌过期的时间，之后不能再使用该令牌对用户进行身份验证。

始终遵守访问令牌响应中提供的令牌生存期或 ID 令牌中的 exp 声明。 控制令牌生存期的条件可能包括企业的登录频率。 你的应用程序无法配置令牌生存期。 你无法请求令牌生存期。

通常情况下，令牌必须有效且未过期。 受众声明 (aud) 必须与客户端 ID 匹配。 确保令牌来自受信任的发放者。 如果有多租户 API，可以选择进行筛选，以便只有特定租户才能调用 API。 确保强制实施令牌的生存期。 检查 nbf（非之前）和 exp（过期）声明，确保当前时间在这两个声明的值范围内。

不要追求特别长或特别短的会话生存期。 让授予的ID 令牌生存期推动此决定。 让应用的会话在令牌有效期后仍处于活动状态，违反了促使 IT 管理员设置令牌有效期，以防止未经授权访问的规则、策略和关注。 会话时间过短会降低用户体验，而且不一定会提高安全状况。 通过 ASP.NET 等常用框架，可以从 Microsoft Entra ID 的 ID 令牌的到期时间设置会话和 Cookie 超时。 遵循标识提供者的令牌到期时间，可确保用户的会话永远不会超过标识提供者规定的策略。

缓存和刷新令牌

请记住要适当缓存令牌。 MSAL 会自动缓存令牌，但是令牌具有生存期。 在令牌的整个生存期内使用并适当缓存。 如果重复请求相同的令牌，限制会导致应用程序响应速度降低。 如果应用滥用令牌发放，则向应用发放新令牌所需的时间会延长。

MSAL 库管理 OAuth2 协议的详细信息，包括刷新令牌的机制。 如果不使用 MSAL，请确保所选库能够有效使用刷新令牌。

当你的客户端获取访问令牌来访问受保护资源时，它会收到一个刷新令牌。 当前访问令牌过期后，可以使用刷新令牌获取新的访问/刷新令牌对。 使用刷新令牌来获取其他资源的额外访问令牌。 刷新令牌绑定到用户和客户端的组合（不绑定到资源或租户）。 你可使用刷新令牌在有权限的情况下跨资源和租户的任何组合获取访问令牌。

管理令牌错误和 bug

应用程序不应尝试验证、解码、检查、解释或审视访问令牌的内容。 这些操作完全由资源 API 负责。 如果应用尝试检查访问令牌的内容，则当 Microsoft 标识平台发放加密令牌时，应用程序很可能中断。

由于网络或基础结构故障，或者由于身份验证服务中断等问题，对检索令牌的调用可能会失败，但这种情况很少发生。 如果发生令牌获取失败，请遵循以下最佳做法，提高应用程序中的身份验证体验复原能力：

  • 使用加密在本地缓存和保护令牌。
  • 不要在非安全通道上传递令牌等安全项目。
  • 了解标识提供者的异常情况和服务响应并采取相应行动。

开发人员通常对查找令牌内部以调试问题存有疑问，例如调用资源时收到 401 错误。 随着越来越多的加密令牌阻止你查看访问令牌内部，你需要找到查看访问令牌内部的替代方案。 对于调试，包含访问令牌的令牌响应提供了所需信息。

在代码中，检查错误类别，而不是单个错误案例。 例如，当系统未授予权限时，应处理所需的用户交互，而不处理个别错误。 由于你可能会错过这些个别情况，因此最好检查是否有分类器（如用户交互），而不是深入了解个别错误代码。

可能需要回退到 AcquireTokenInteractive 并提供 AcquireTokenSilent 调用所需的声明质询。 这样做可确保有效管理交互式请求。

后续步骤