通过

管理零信任身份令牌

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

确保应用程序遵循 最低特权的 零信任原则，并防止使用损害意图的方式。 使用实时和恰好足够的访问权限 (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、email 和 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 为用户创建会话。 用户会话管理驱动用户需要重复身份验证的频率。 其在确保被明确验证的用户以适当的权限和适当的时间长度停留在应用面前方面的作用至关重要。 会话生存期必须基于 exp ID 令牌中的声明。 声明 exp 是 ID 令牌过期的时间，之后不能再使用该令牌对用户进行身份验证的时间。

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

一般情况下，请确保令牌有效且未过期。 用户声明（aud）必须与客户端 ID 匹配。 确保令牌来自受信任的颁发者。 如果有多租户 API，可以选择筛选，以便只有特定租户才能调用 API。 请确保令牌的存续期得到强制执行。 检查nbf（不得早于）和exp（过期）声明，以确保当前时间符合这两个声明的要求。

不要设定过长或过短的会话生存期。 让授予的 ID 令牌生存期 驱动此决定。 使应用的会话保持活动状态超出令牌有效性，违反了导致 IT 管理员设置令牌有效性持续时间的规则、策略和担忧，以防止未经授权的访问。 短会话会降低用户体验，不一定增加安全态势。 借助像 ASP.NET 这样的常用框架，可以基于 Microsoft Entra ID 令牌的过期时间来设置会话和 cookie 的超时。 按照标识提供者的令牌过期时间，确保用户的会话永远不会超过标识提供者所指示的策略。

缓存和刷新令牌

请记得适当缓存令牌。 MSAL 会自动缓存令牌，但令牌具有生存期。 在其生命周期中使用令牌，并适当地缓存。 如果重复请求相同的令牌，限流控制会导致应用程序响应速度变慢。 如果应用滥用令牌颁发，则向应用颁发新令牌的时间会延长。

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

当客户端获取访问令牌以访问受保护资源时，它会收到刷新令牌。 使用刷新令牌在当前访问令牌过期后获取新的访问/刷新令牌对。 使用刷新令牌获取额外的访问令牌以访问其他资源。 刷新令牌与用户和客户端的组合绑定，而不是与资源或租户。 您可以使用刷新令牌在您的应用拥有权限的资源和租户的任意组合中获取访问令牌。

管理令牌错误和漏洞

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

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

  • 在本地使用加密技术缓存和保护令牌。
  • 不要在非安全通道上传递安全项目，如令牌。
  • 了解并处理标识提供者提供的异常和服务响应。

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

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

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

后续步骤

  • Last updated on