这开始是一个评论，但它变得有点大，所以我把它移到了“答案”。

OAuth2.0 规范中缺少的步骤是“后端通信”：授权服务器和各种服务就什么是有效令牌以及与之关联的范围达成一致的部分。这些“实施细节”由 OAuth 服务提供商自行决定。

此外，可以通过更接近 OAuth2.0 术语来改进您的图表（我并不是说您做得不好，图表很有帮助，但可能更清楚）。

在这种情况下，您的“用户”（大概）是资源所有者。“前端”可能（我在这里猜）是一个单页应用程序，在User Agent内运行。

API 服务器从授权服务器接收访问令牌，以代表资源所有者访问数据。

换句话说，您的图表缺少“用户”和“身份验证服务器”之间的通信。

对于 OAuth 的流程，也许下图会有所帮助：

^{图 1：（机密）客户端的 OAuth 流程。}

回答您的问题：OAuth 是关于从资源所有者授权某些服务以代表他们访问资源所有者的数据。

因此，使用 OAuth 可能不是您的最佳选择。但是，我不知道有任何开箱即用的解决方案可以真正解决您的问题（代表用户授权访问权限）。您可以查看基于授权的访问控制 (ZBAC)，但对于您想要实现的目标而言，这可能有点过头了。

你的尝试已经成功了一半。

OAuth2 中有一种授权类型，称为Client Credentials，这可能是您正在寻找的。

客户端使用客户端凭据授予类型来获取用户上下文之外的访问令牌。

基本上，客户端将其客户端 ID 和客户端密钥交换为访问令牌，然后它可以使用该令牌代表自己向资源服务器发出请求。

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

查看这些以获取更多信息：

https://oauth.net/2/grant-types/client-credentials/

https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/

也许我遗漏了一些东西，但是如果那时您只想控制哪些服务可以调用给定的服务 X ，例如它们可以调用所有端点或不调用端点，那么为什么不使用基本身份验证和服务 X？然后，另一个服务将具有服务 X 的基本身份验证凭据，或者没有。显然这里的坏处是 - 如果凭据泄漏，您需要更新所有拥有它们的服务。个人凭据限制了该范围，并允许您根据使用的凭据识别呼叫者。