为什么我们在资源和授权服务器中需要完全相同的配置

Question

我说的是这两个是独立的应用程序的情况。我对在一个应用程序中合并它们不感兴趣。因此，在授权服务器中，我们扩展AuthorizationServerConfigurerAdapter类，并在资源服务器ResourceServerConfigurerAdapter中，我们创建完全相同的bean，如JwtAccessTokenConverter，DefaultTokenServices等，但大多数我不明白为什么我们在两者中都需要TokenStore。

这是否意味着我们在内存中存储了不同应用程序中的相同令牌？

删除此代码重复的最佳方法是什么？为普通类创建一个库？请求auth服务器验证令牌？但是，如果我们在资源服务器中没有解码逻辑，我们如何从JWT令牌中提取更多信息？

Answer 1

这是否意味着我们在内存中存储了不同应用程序中的相同令牌？

https://auth0.com/learn/json-web-tokens/

这是一种无状态身份验证机制，因为用户状态永远不会保存在服务器内存中。服务器的受保护路由将在Authorization标头中检查有效的JWT，如果有，则允许用户。由于JWT是独立的，所有必要的信息都在那里，减少了返回数据库的需要。

---

删除此代码重复的最佳方法是什么？为普通类创建一个库？

如果使用对称密钥：

@Bean
    public JwtAccessTokenConverter accessTokenConverter() {
        JwtAccessTokenConverter converter = new JwtAccessTokenConverter();
        converter.setSigningKey("123");
        return converter;
    }

JwtAccessTokenConverter，DefaultTokenServices等在资源服务器和认证服务器中都是相同的bean，因此您可以为这两个bean的声明创建一个公共项目，并将它们作为依赖项添加到两个项目中。

但是，如果使用非对称KeyPair，则beans声明会完全更改，并且它们可能不一样。

您可以在此处查看有关此差异的更多信息：

https://www.baeldung.com/spring-security-oauth-jwt

---

请求auth服务器验证令牌？

JWT的主要优势是不必这样做。

---

但是，如果我们在资源服务器中没有解码逻辑，我们如何从JWT令牌中提取更多信息？

如果使用对称密钥，则可以在资源服务器中解码逻辑。

Answer 2

在微服务系统中解决这种情况的最佳方法是创建一些实体：API编写器，授权服务和业务服务。

该方案的基本机制是：

首先，您将未经授权和授权的请求与令牌标题分开。通常，它的名称类似于“X-AUTHORIZATION-HEADER”或类似的东西。在此标头中，您将JWT令牌放在服务器的网关上，该角色正在执行“API Composer” - 它是某种接受请求的路由器，并将它们传递给适当的收件人。

特别是，API编写器接受响应，解析标头，使用令牌查找适当的标头，并将其发送到Auth服务并接收用户或错误的响应。在这个方案中，你需要像JwtAccessTokenConverter这样的实体，而只需要在Auth服务中

然后，聚合响应有效负载将完成，您的API将响应发送给客户端。

我在开发微服务系统时使用这个方案，对我来说它运行正常。

希望，我正确理解你的问题，我的回答将对你有所帮助）最诚挚的问候。