问题描述
我想知道是否有人通过示例来了解如何使用Spring Cloud Security(使用OAuth2)实现令牌交换"技术.
I would like to know if someone has an example to see how to implement "Token Exchange" technique with Spring Cloud Security (with OAuth2).
目前，我已经在微服务环境中使用ZuulProxy实现了令牌中继"技术，以中继" OAuth2令牌并实现了SSO.这很棒，但是意味着每个微服务都使用相同的clientId(在ZuulProxy设置中指定，因为ZuulProxy仅使用授权代码授权类型和提供的clientId中继令牌).但是，对于微服务内调用，我想交换"令牌.这意味着在某些情况下，ZuulProxy中继的令牌不是我作为微服务B的客户端对微服务A进行身份验证/授权所需要的令牌.
Currently I have implemented "Token Relay" technique in a Microservices Environment using ZuulProxy to "relay" the OAuth2 token and implementing SSO. This is great but implies that every microservice uses the same clientId (which is specified in ZuulProxy setup as ZuulProxy relays the token only with authorization_code grant type and the clientId provided).However, for intra-microservices calls I would like to "exchange" the token. This means in some cases the token that ZuulProxy relays is not the one I need to use to authenticate/authorize Microservice A as client of Microservice B.
Spring Cloud参考文档目前说:在Spring Boot和Spring Security OAuth2的基础上，我们可以快速创建实现常见模式(如单点登录，令牌中继和令牌交换)的系统." ( http://cloud.spring.io/spring-cloud-security/spring-cloud -security.html )
The Spring Cloud reference documentation currently says: "Building on Spring Boot and Spring Security OAuth2 we can quickly create systems that implement common patterns like single sign on, token relay and token exchange." (http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html)
我想参考文档中的令牌交换"是指OAuth2扩展的实现，如本规范所述，这基本上是我所需要的: https://tools.ietf.org/html/draft-ietf-oauth-token- exchange-03
I guess that with "Token Exchange" in the reference documentation they mean the implementation of this extension of OAuth2, explained in this spec, which is basically what I need:https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03
正如我所说，我了解如何使用SSO和令牌中继，但是在参考文档中看不到有关如何实现令牌交换"的进一步说明.我也找不到一个实现示例.
As I said, I understand how to use SSO and Token Relay but I'm not able to see further explanation about how to implement "Token exchange" in the reference documentation. I was not able to find an implementation example either.
有人知道我在哪里可以找到更多信息或示例吗?
Does anyone know where I can find further information or an example?
非常感谢！
推荐答案
我很好奇为什么您需要交换"令牌以进行从微服务A到微服务B的呼叫，以及为什么中继不足?通过为服务间请求交换令牌，您想实现什么?
I'm curious why you'd need to "exchange" the token for making calls from Microservice A to Microservice B and why relaying is not sufficient? What are your trying to achieve by exchanging tokens for inter-service requests?
我们的设置与此北欧API条目.简短的版本是外部调用者使用一个不透明的令牌，但是一旦请求通过我们的网关，每个微服务都将获得相同令牌的JWT表示形式.我们必须实现一个自定义端点，以执行JWT交换的不透明操作.当服务需要彼此交互时，当A需要调用B时，我们不交换令牌，我们只是中继令牌. RestTemplate或Feign客户端都会自动将令牌从A转发到B.因此，上下文不会丢失.
We have a set up very similar to what is described in this Nordic APIs entry. The short version is that external callers use an opaque token, but once the request goes through our gateway, every microservice gets a JWT representation of the same token. We had to implement a custom endpoint to to perform the opaque to JWT exchange. When services need to interact with one another, we do not exchange the token when A needs to call B, we simply relay the token. Either the RestTemplate or Feign client will automatically forward the token from A to B. Thus, context is not lost.
现在，如果我们想控制访问权限，那么JWT可以指定一组受众群体值，也可以通过作用域强制访问.实际上，我们会根据用例将两者结合起来.
Now, if we wanted to control access, the JWT could specify a collection of audience values or we could enforce access via scopes. We are actually doing a combination of the two depending on the use case.
交换令牌并不是一个便宜的操作，实际上，这在规模上是相当昂贵的，并且应该真正考虑为什么需要进行令牌交换以进行服务内通信.如果每个API请求都将导致服务A调用服务B，并且必须进行令牌交换，则将确保您的授权服务可以处理这种类型的工作负载.最后，IETF代币交换仍处于起草状态，并且在其演变过程中发生了很大变化，因此在规范接近最终定稿之前，我对实施建议的期望不高.
Exchanging tokens is not a cheap operation, in fact it's quite expensive at scale and should really consider why you need to do a token exchange for intra-service communication. If you every API request is going result in service A calling service B and you have to make a token exchange, you're going to have ensure that your authorization service can handle that type of workload. Lastly, the IETF token exchange is still draft status, and has changed quite a bit in its evolution, so I would not expect much in the way of implementation advice until the spec gets closer to finalization.
这篇关于如何实现OAuth2“令牌交换"?使用Spring Cloud Security的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！