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

我说的是这两个应用程序是分开的情况。我对将它们合并到一个应用程序中不感兴趣。 因此，在授权服务器中，我们扩展了

AuthorizationServerConfigurerAdapter

类，在资源服务器

ResourceServerConfigurerAdapter

中，我们在两者中创建了完全相同的bean，如

JwtAccessTokenConverter

，

DefaultTokenServices

等等。但我不明白为什么我们需要

TokenStore

这两种服务

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

---

消除代码重复的最佳方法是什么？为公共类创建库？是否向身份验证服务器发出验证令牌的请求？但是，如果资源服务器中没有解码逻辑，我们如何从JWT令牌中提取更多信息？

在微服务系统中解决此问题的最佳方法是创建一些实体：API编写器、授权服务和业务服务

该方案的基本机制是：

首先，使用令牌头将请求与未授权和授权分开。通常，它的名称类似于“X-AUTHORIZATION-HEADER”或类似的名称。在这个标题中，您放置JWT令牌并将其发送到服务器的网关上，该网关的角色正在执行“API Composer”——它是一种路由器，它接受请求，并将请求传递给相应的收件人

特别是，API composer接受响应，解析标头，找到带有令牌的适当标头，并将其发送到Auth Service并接收带有用户或错误的响应。在这个方案中，您需要像

JwtAccessTokenConverter

这样的实体，否则只能在Auth服务中使用

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

我在开发我的微服务系统时使用了这个方案，对我来说，它工作得很好

希望，我正确地理解了您的问题，我的回答是：将帮助您）致以最诚挚的问候。

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

这是一种无状态身份验证机制，因为用户状态从未保存在服务器内存中。服务器的受保护路由将检查授权标头中是否存在有效的JWT，如果存在，则允许用户使用。由于JWT是自包含的，所以所有必要的信息都在那里，从而减少了来回访问数据库的需要

---

消除代码重复的最佳方法是什么？为公共类创建库

如果使用对称密钥：

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

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

但是，如果使用非对称密钥对，那么bean声明将完全改变，它们不可能是相同的

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

---

是否向身份验证服务器发出验证令牌的请求

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

---

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

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