OAuth2/OpenID Connect 保护 API 的自动化 API 测试

Question

我正在研究一个新项目，我们计划先做 API，这样我们就可以在上面实现 Web 和本地应用程序，并允许第三方集成。到目前为止，一切都相当标准。

我们还希望为 API 提供一整套自动化测试，以确保它在没有回归的情况下工作，并确保它满足要求。同样，相当标准，但因为我们正在测试 API，我们将使用代码内 HTTP 客户端而不是 Web 浏览器。

我们一直在研究 oauth2/OpenID Connect 以促进 API 的身份验证和授权 - 基本上，客户端可以进行身份​​验证、获取访问令牌，然后使用它来访问所有 API 资源。

我正在努力解决的问题是让自动化测试与 oauth2 部分一起工作以便能够实际调用 API 的好方法。第一个想法是使用“client_credentials”或“password”授权类型，它们看起来都可以满足我们的需求，但 OpenID Connect 规范根本没有涵盖它们，当然还有“password” " 至少它通常被认为不是一个好主意。

这是实现这一目标的最佳方式，还是在这种情况下是否有其他最佳实践可以与其他流程一起使用，但没有网络浏览器？

编辑：在（更多）阅读之后，我有了一个新计划。完全离线运行测试，针对单独的数据库使用单独的部署，并在测试运行之前将数据直接播种到数据库中，然后使用标准的 OpenID Connect 流程，但使用：

• 在数据库中标记为用于测试目的的客户端。这一点很重要，只有当客户端可以直接注册到数据库中而不经过业务逻辑时才有可能。
• 提示=无
• login_hint=获取访问令牌的用户名
• 范围包含“测试”

然后系统可以检测到这些事实组合，并自动验证提供的用户名，而无需通过浏览器。

这看起来合理吗？还是有更好的办法？

Answer 1

由于您要测试 API，因此无论您是通过浏览器还是通过其他方式获得 access_token 都无关紧要。所以有（至少）两种解决方案：

1. 另一种方式可能是client_credentials 授权。你会 必须让授权服务器返回一个access_token 类似于一个access_token，它将为 OpenID 中的用户返回 通过浏览器连接流，但取决于您的 AS 应该是可行的。

2. 使用常规的 OpenID Connect 浏览器流程引导您的客户端，以在 access_token 旁边生成一个 refresh_token，并在配置时将这两个令牌与 client_id 和 client_secret 一起存储在您的测试客户端中。然后，您的测试客户端可以访问 API，直到 access token 过期，随后通过 refresh_token 授权类型（利用 client_id 和 client_secret）获得新的 access_token。

OpenID Connect 本身、用户身份验证和id_token 与您应该只关心access_token 的API 无关。