在服务之间传递OAuth访问令牌是否可行？

Question

考虑在SSO/OAuth/microservices的背景下，以下情况：

1. 用户使用OAuth的Implicit Flow成功登录Web应用程序。
2. Web应用程序使用用户的访问令牌向Service A和Service B请求一些数据以授权两个请求。
3. Service A还调用Service B(传递相同的访问令牌!)，以便构建响应初始Web应用程序请求。

现在，从Service A传递用户的访问令牌到Service B是否可以？

还是应该Service A使用"客户端凭据"授予来获取自己的访问令牌，以授权对Service B的调用？

更新:
请假设这两个服务都归同一组织所有，并且都信任同一个授权服务器。而且这两个服务都在同一个API网关后面，该网关验证访问令牌。

- begie

Answer 1

这取决于谁控制着Web应用程序、服务A和服务B。如果它们都由同一方运行，那么传递令牌不会有问题，因为它仍然在同一安全域中。

但是，如果例如服务B由第三方运行，则会出现问题，因为服务B的管理员可以拾取访问令牌并调用服务A，就像它是您的Web应用程序一样，潜在地获取了不应该具有访问权限的资源。

您还应该注意，如果服务A和服务B归两个与您不同的组织所有，那么您的Web应用程序也应分别获取两个不同的访问令牌来调用服务A和服务B，以防止出现相同的安全问题。

因此，答案真的是：这取决于谁控制什么，即令牌是否越过管理/安全域。

- Hans Z.

---

所以你的意思是只要Web应用程序和两个服务都由同一组织控制/拥有，就可以了？您是否知道任何文档（RFC、OAuth指南等）涵盖这种情况？我之所以问是因为我同意您的答案，并且正在寻找额外的“弹药”与我的公司内SSO团队讨论此问题。 - begie

这是一个通用的安全考虑：访问令牌不应泄露到客户端/资源服务器/授权服务器之外，请参见：https://tools.ietf.org/html/rfc6819#section-4.6.1 - Hans Z.

实际上，在OAuth Implict Flow的情况下，访问令牌必须超出RS/AS边界。在授权代码流或客户端凭据流的情况下，确实不应该泄漏令牌到RS/AS边界之外。 - begie

令牌始终发送到客户端，无论授权类型如何，因此它们始终离开RS / AS；关键是它们不会泄漏到与预期客户端/ RS不同的其他客户端/ RS。 - Hans Z.

好观点。实际上，当我说在授权码流程中令牌不会离开客户端/RS/AS边界时，我是想到了用户代理。 - begie

Answer 2

我认为，如果有两个不同的服务都信任同一个身份提供者（STS），那么可以让服务A请求一个令牌，然后将同一个令牌传递给服务B，并让服务B再次验证该令牌。可以传递令牌，因为您不希望用户为另一个服务调用再次登录。

此外，这取决于您设置服务的方式。如果服务A需要从服务B获取一些数据以向用户提供数据，则应传递相同的用户令牌。我认为服务不应该拥有自己的访问令牌。

使用用户令牌确实有助于识别每个服务级别的声明和数据访问。因此，最好传递用户令牌，并在将数据发送给用户之前让每个服务验证该令牌。

- Mitra Ghorpade

---

实际上，OAuth 2.0 定义了“客户端凭证”授权类型，因此通常情况下，服务 A 调用其他服务 B 可以使用此授权类型来获取自己的访问令牌。我的问题是关于一个特定情况，即当服务 A 已经拥有用户的访问令牌时，技术上可以重复使用该令牌来调用服务 B。问题是这样做是否正确。 - begie

是的，将服务令牌传递给其他服务是可以的，因为您不希望任何服务面向公众开放。例如，Service A 的响应需要来自 Service B 的某些数据，则用户无需知道这一点。此外，在 Service B 可以独立调用以及从 Service A 调用的情况下，无论谁调用该服务以获取数据，都必须提供令牌。在 A 调用时，它将传递已经拥有的令牌，而当用户调用它时，他将传递令牌。 - Mitra Ghorpade

Answer 3

我找到了以下三个选项：

• 如果每个微服务都验证令牌，那么我们可以传递相同的令牌。但问题是 - 在同一令牌之间可能会过期。

• 如果我们使用client_credentials授权，则存在两个问题：一个是，我们需要在下一个微服务中发送用户名/ID。另一个是，我们需要请求两次 - 首先获取访问令牌，然后进行实际调用。

• 如果我们只在API网关中进行令牌验证（而不是在微服务中），则我们需要从API网关中向每个微服务发送用户名。并且需要更改微服务实现以接受该参数/标头。

- Myth