背景
我有一个应用程序，它有一个节点后端和一个角度前端。后端有两个GraphQl端点：
-
/auth，其方法如下：signIn，它从我的角度前端验证一个交互式用户(基本的usr/pwd)，并返回一个访问令牌和一个安全的httpOnly刷新令牌(cookie)；refreshToken，返回新的接入令牌；和signOut，它只是撤销刷新令牌。 -
/api，包含业务规则，并通过接收到的访问令牌(无状态)验证请求
angular前端通过调用/auth/signIn端点来验证用户，将访问令牌保存在内存中，不知道httpOnly刷新令牌，并创建一个计时器来定期调用/auth/refreshToken。
问题
我也需要向我的客户授予以编程方式访问/api的权限(例如来自Zapier)，所以我们讨论的是API-KEY，对吗？我考虑在前端的SETTINGS区域中创建一个API-KEY部分，并在/auth端点中创建CRUDE方法来维护它们。我将在与生成的API-KEY链接的用户表中创建一个新的特殊非交互式"用户"，这样，例如，用户Zapier将与为与Zapier交互而创建的API-KEY相关，我可以在审计跟踪中看到其活动和其他用户活动，并通过删除该用户轻松撤销该活动。
问题
我应该使用一个长期(？)访问令牌作为API-KEY吗？这难道不会破坏使用访问令牌的目的吗？我的/api将不再是无状态的，我必须检查每个请求的访问令牌是否存在，对吧？这似乎不是一个正确的选择有更好的方法吗
使用刷新令牌作为API-KEY对我来说似乎不是一个选项，第一，因为似乎不允许在客户端设置httpOnly cookie，第二，因为更新访问令牌的逻辑对用户来说太复杂，第三，因为我不想公开/auth端点。
neneneba API密钥的安全性非常弱，因此这最终取决于数据敏感性，例如如果攻击者能够长时间轻松访问您的数据，这是否严重。
我倾向于为客户端类型提供标准的OAuth流——也许是客户端凭据授予——以便使用访问令牌，这些令牌在有限的时间段内有效，例如30分钟。过期和刷新编码在网上有很好的记录。
-
如果它是一个用户应用程序，那么该应用程序(或其后端)可能需要做一些工作来正确获取令牌。
-
如果客户正在编写代码以使用代码调用API，则需要向他们提供如何验证和管理到期的指导。这些细节在网上有很好的记录。
-
如果这些用户是非常非技术性的，那么附加令牌甚至可以由出站代理进行管理，其中代理负责提供令牌。