我现在正试图集中精力关注网络安全问题一段时间。假设我们有一个如下图所示的系统设置。

有一个主要应用程序，用户大部分时间都通过前端与之交互。除了主应用程序之外，还有多个较小的应用程序。这些应用程序还具有用户可以与之交互的前端。由于我们不想为每个应用程序使用不同的用户数据库，因此我们决定使用 oAuth2 进行身份验证。

主应用程序可以与这些其他系统交互，反之亦然。大多数时候它是在用户交互的上下文中。

从主应用程序到其他应用程序的请求必须（1）授权和（2）我们想知道在“其他应用程序”中代表哪个用户发起了呼叫（不是“主应用程序”，而是“用户” ）。

将用户 oAuth 令牌从主应用程序发送到其他应用程序真的很诱人。但这可能会产生严重的安全隐患，因为“其他应用程序”现在拥有用户使用主应用程序的所有权利（https://www.rfc-editor.org/rfc/rfc6749#section-10.3）。

这可能不是那么糟糕，因为我们自己管理这些服务，但如果我们正在处理 3rd 方应用程序，这肯定不是正确的方法。

总之，我的问题是：如果用户在应用程序上发起请求，而该应用程序又必须调用另一个应用程序来完成请求，我们如何：

• 授权从应用程序到其他应用程序的第二次调用（假设用户已获得授权并且我们有一个中央 oAuth 身份验证系统）
• 并且仍然以某种方式知道呼叫是代表哪个用户发起的。

理想情况下，呼叫的接收端甚至不知道呼叫是由其他应用程序发起的（它只会认为这是来自用户的直接呼叫）。它只会使用已经存在的 oAuth 安全拦截器。

编辑：

我的一个想法是向授权服务器添加一些额外的授权授权类型，该授权服务器作为输入：

• 有效的资源所有者凭据
• 发起请求的用户的有效令牌
• 我们将要访问的资源服务器的 ID

授权服务器知道，给定请求的资源所有者凭据：

• 允许使用哪些资源服务器 ID
• 可以从原始令牌中保留哪些权限

授权服务器：

• 验证请求的资源服务器凭据
• 验证用户令牌
• 验证是否允许请求资源服务器为请求的资源服务器请求令牌
• 保留用户令牌上的用户权限和请求资源服务器的允许用户权限的交集

结果是一个短暂的（不可刷新的）令牌

• 代表请求用户
• 只有我们将作为观众访问的资源服务器的 ID
• 具有原始令牌的权限子集。