我们计划在两个服务之间进行集成：A 和 B。
A 服务将成为 OpenID 提供者，B 服务依靠它来登录用户并创建新帐户。
A 服务还使用 OAuth 授权通过 REST API 提供对其资源的访问，B 服务使用通过 OpenID 授权代码流获得的 OAuth 访问令牌。
但是，在某些情况下A 想要从B 获取数据。这些服务之间有一个既定协议，A 可以在通过 OpenID Connect 创建的用户范围内访问来自B 的任何数据。
如何为服务B API 设计授权？ A 可以在 HTTP 请求中向 B 提供什么？
我正在考虑像经典的 API Key 这样的东西，但在这个工作流程中看起来并不自然。
【问题讨论】：
标签： rest api oauth openid-connect api-design
从 OAuth 和 OpenID Connect 协议的角度来看，您提到的场景没有直接的解决方案。
但根据您的解释，您在 service A 中拥有 OAuth 2.0 访问令牌保护服务。此外，A 充当身份提供者（支持 OpenID Connect）。如果是这种情况，我相信您可以控制令牌发布过程和验证。
一种选择是启用来自 B 的服务，这些服务受到 OAuth 2.0 访问令牌的保护。这类似于您在A 中已有的内容。为了使用这些服务，您将拥有一些绑定到A 的服务/客户端实现。他们会做的是从A 本身获取令牌以与B 通信。这可以遵循client credential grant from OAuth 2.0，因为没有最终用户参与（场景涉及服务到服务的交互）。
这个建议的解决方案类似于 API 密钥的使用，但增加了 OAuth 2.0 协议的好处。这允许您生成具有有限生命周期的访问令牌，并允许在需要时刷新它们。此外，如果您希望 B 的服务被另一个客户端使用，那么事情就很简单了。
【讨论】：