我有一个 Web 应用程序 (SPA)，我们将其称为 A。该应用程序调用 API 服务（由我控制），我们将其称为 B。服务 B 使用 OAuth 身份验证，并信任颁发者 I。
在我的场景中，还有另一个我不控制的 API 服务 C（也使用 OAuth 身份验证并信任颁发者 I）。在某些情况下，我需要服务 B 调用服务 C 来响应用户从 A 到 B 的请求。我可以在这里看到两个（明显的）选项：
- 用户通过应用程序 A 使用“带有 PKCE 的授权代码流”进行身份验证，并接收身份令牌。 A 可以将此身份令牌交换为具有服务 B 所需范围的访问令牌。应用程序 A 使用访问令牌向 B 进行身份验证，并将身份令牌与请求一起传递，B 使用身份令牌请求具有服务 C 必要范围的访问令牌。B 使用此（新的、第二个）访问令牌向服务 C 发出一个或多个请求。这看起来很糟糕，因为人们“永远不会”应该将身份令牌传递给任何服务。
用户通过应用程序 A 使用“带有 PKCE 的授权代码流”进行身份验证，并接收身份令牌。 A 可以将此身份令牌交换为具有服务 B 的必要范围的访问令牌。然后，应用程序 A 使用身份令牌请求具有服务 C 的必要范围的第二个访问令牌。A 使用第一个访问令牌进行身份验证服务 B，并随请求传递第二个访问令牌。服务 B 使用此第二个访问令牌代表用户向服务 C 发出一个或多个请求。这看起来没那么糟糕，但仍然不是很好。
-
据我所知，不可能请求和访问同时适用于 B 和 C 的令牌，因为它们是单独的资源（而不仅仅是同一资源中的不同范围）。在我看来，这是一个非常常见的情况；我的 API 服务是否需要代表用户向 Blob 存储（即 Azure Blob 存储或 S3）发出请求，或者向数据库服务器发出请求？
是否存在我不知道的第三种情况，或者其中一种是正确的方法？