我应该使用访问令牌作为 API-KEY 吗？

Question

背景

我有一个带有节点后端和角度前端的应用程序。后端有两个 GraphQl 端点：

• /auth，其方法如下： signIn，从我的角度验证交互式用户（基本 usr/pwd）并返回访问令牌和安全的 httpOnly 刷新令牌（cookie）； refreshToken，返回一个新的访问令牌；和 signOut，它只是撤销了刷新令牌。

• /api，包含业务规则，通过接收到的访问令牌（无状态）对请求进行认证

Angular 前端通过调用/auth/signIn 端点对用户进行身份验证，将访问令牌保存在内存中，不知道 httpOnly 刷新令牌，并创建一个计时器来定期调用/auth/refreshToken。

问题

我也需要授予我的客户以编程方式访问/api 的权限（例如，来自 Zapier），所以我们在谈论 API-KEY，对吗？我正在考虑在前端的 SETTINGS 区域和 /auth 端点的 CRUDE 方法中创建一个 API-KEY 部分来维护它们。我将在链接到生成的 API-KEY 的 users 表中创建一个新的特殊非交互式“用户”，例如，用户 Zapier 将与创建用于与 Zapier 交互的 API-KEY 相关，我可以看到它的审计跟踪中其他用户活动的活动，并通过删除该用户轻松撤销它。

问题

我应该使用长期 (?) 访问令牌作为 API-KEY 吗？这不会破坏使用访问令牌的目的吗？我的/api 将不再是无状态的，我必须检查每个请求的访问令牌是否存在，对吗？这似乎不是正确的选择。 有更好的方法吗？

使用刷新令牌作为 API-KEY 对我来说似乎不是一个选项，首先，因为它似乎不允许在客户端设置 httpOnly cookie，其次，因为更新的逻辑访问令牌对用户来说太复杂了，第三，因为我不想暴露 /auth 端点。

Answer 1

API 密钥的安全性非常弱，因此最终这取决于数据敏感性，例如攻击者是否可以轻松地长时间访问您的数据是否严重。

我倾向于为客户端类型使用标准 OAuth 流程 - 可能是 Client Credentials Grant - 以便使用访问令牌，这些令牌在有限的时间段内有效，例如 30 分钟。过期和刷新编码在网上有很好的记录。

• 如果它是用户应用程序，那么该应用程序（或其后端）可能需要做一些工作才能正确获取令牌。

• 如果客户正在编写代码以使用代码调用 API，那么他们需要获得有关如何验证和管理过期的指导。这些细节在网上都有很好的记录。

• 如果这些用户非常非技术性，甚至可以由出站代理管理附加令牌，其中代理处理提供令牌。