【发布时间】:2016-04-26 15:05:11
【问题描述】:
我想知道是否有人有一个例子来看看如何使用 Spring Cloud Security(使用 OAuth2)实现“令牌交换”技术。
目前我已经在微服务环境中实现了“令牌中继”技术,使用 ZuulProxy 来“中继”OAuth2 令牌并实现 SSO。这很好,但意味着每个微服务都使用相同的 clientId(在 ZuulProxy 设置中指定,因为 ZuulProxy 仅使用 authentication_code 授权类型和提供的 clientId 中继令牌)。 但是,对于内部微服务调用,我想“交换”令牌。这意味着在某些情况下,ZuulProxy 中继的令牌不是我需要用来验证/授权微服务 A 作为微服务 B 的客户端的令牌。
Spring Cloud 参考文档目前说:“基于 Spring Boot 和 Spring Security OAuth2,我们可以快速创建实现常见模式的系统,例如单点登录、令牌中继和令牌交换。” (http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html)
我想参考文档中的“令牌交换”是指 OAuth2 扩展的实现,在本规范中进行了解释,这基本上是我需要的: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-03
正如我所说,我了解如何使用 SSO 和令牌中继,但我无法在参考文档中看到有关如何实现“令牌交换”的进一步说明。我也找不到实现示例。
有人知道我在哪里可以找到更多信息或示例吗?
非常感谢!
【问题讨论】:
-
同意。在所有微服务中重新使用 client_id 似乎是错误的。最糟糕的部分(在我看来)是它阻止了微服务被其他客户端使用。假设您有另一个具有自己的 client_id 的 sso 客户端......那么您不能使用任何现有的微服务?希望这得到解决。似乎已经完成了一些代币交换工作,但尚未完成/合并github.com/spring-projects/spring-security-oauth/pull/957
-
乍一看,我同意你的看法。但从您的客户的角度来看,他们将您的 API 网关视为一个奇点。从他们的角度来看,只有一个 API。您背后拥有多项服务这一事实是一个实施细节,不一定是您想向客户提供的服务。你决定将一个服务分成两个服务会发生什么?您是否必须让每个人重新发行授予新资源 ID 的令牌?
标签: spring spring-boot spring-cloud spring-oauth2