API 授权类型的访问策略

应用访问策略后，解决了以下基本业务需求：

• 用户是否已充分认证以访问此应用程序？
• 是否允许已认证的用户访问此应用程序？
• 是否允许用于访问此应用程序的设备或客户机上下文？

在传统浏览器流程中，将应用这些需求。 如果未满足，那么浏览器将提示 MFA ，或者它会向用户返回一个错误页面，该页面将使访问停止。 在 API 授权类型中，这些功能并非全部可用。 因此，必须解决以下问题。

• 接收来自客户机设备的上下文。
• 返回 MFA 质询，包括
  • 实现 MFA 所需的 API。
  • 如何访问 API。

Policyauth 授权类型

为了将访问策略有效地应用于仅限 API 的 OAuth 2.0 流，引入了新的授权类型。 此授权类型允许客户机在任何认证之前向访问策略提供一些上下文。 这种能力可以实现增强的用户体验。 例如，当用户按登录按钮时，在系统提示其输入任何凭证前，根据相关策略对其进行评估。 如果它们不满足策略需求，那么用户将接收到错误消息，指示由于策略需求，他们无法认证或访问资源。

来自 /token 的 MFA 质询响应

当访问策略应用于 API OAuth 2.0 流时，MFA 的质询必须成为 API 合同的一部分。 在请求 /authorize 的过程中执行 MFA 步骤的 OP 的传统方法是不可能的。

当 MFA 质询由 /token返回时，

• 作用域为 mfa_challenge，并且不会返回其他作用域。
• 发出访问令牌。
  • 访问令牌有权访问必需的认证 API。 使用此访问令牌，而不是常规 API 客户机访问令牌非常重要。 此令牌用于在授予中跟踪已执行的认证因子和过去的操作。
  • 访问令牌从 /introspect 请求返回 active: true。 任何保护资源服务器的 API 都必须在使用 MFA 质询时，实现从 /introspect 返回的 scope 不等于 mfa_challenge 的检查。
• （可选）列出了可以执行以满足此质询 allowedFactors 的因子数组。

向 /token 提供上下文

向 /token 执行请求的 API 客户机可以向 /token 提供明确定义的任意上下文信息，以便在访问策略评估中使用。

必须包含三个必需的上下文信息。

• sessionId - OAuth 客户机发出的和维护的任意会话标识。
• ipAddress - 因为 OAuth 客户机负责与用户代理的交互，所以必须明确提供用户 IP 地址。
• userAgent - 与 IP 地址类似，必须明确提供用户的用户代理。

可以包含更多参数，并且可以在这些值上创建上下文属性条件。

上下文以 base64 编码的 JSON 格式提供给 /token。 上下文的 JSON 有效内容示例为：

{
    "sessionId":"MDNjZmQ3NDM2NjFmMDc5NzVmYTJmMT",
    "ipAddress":"129.42.38.10",
    "userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"
}

上下文信息被认为是可信的，因为它由发出了一组安全客户机凭证的 API 客户机提供。 该 API 客户机必须确保它不允许由消耗性的用户代理任意提供上下文，该用户代理可用于绕过业务控制。

在调用所有 API 授权类型（包括 policyAuth JWT Bearer、、 ROPC 和 refresh token）的访问策略时，必须提供上下文。

满足 mfa_challenge

为满足由 /token 端点返回的 MFA 质询，可以使用认证因子 API。 这些 API 用于满足第一和第二因子需求。 在 mfa_challenge 响应中返回的访问令牌用于请求相应的因子。 因子成功完成后，将返回 JWT。 此 JWT 包含一些关键信息。

• 派生自用于请求因子 API 的访问令牌的 grant_id。 此标识在 /token 的不同请求中维持相关性。
• 已执行的操作 factor 以及之前执行过的任何因素。

此 JWT 作为 jwtBearer 授权类型流的一部分提供给 /token。 将重新评估访问策略，并发出完全授权的令牌或其他质询。

将访问策略应用于不同授权类型

配置应用程序时，存在访问策略是否应用于特定授权类型的选项。

此配置控制是否对基于 grant_type 参数值的 /token 请求评估访问策略。 无论对特定授权的任何先前 /token 调用情况如何，此评估都适用。