@Configuration
@EnableResourceServer
public class WebClientResourceConfig extends ResourceServerConfigurerAdapter {

    private final AuthClientExceptionHandler authClientExceptionHandler;

    public WebClientResourceConfig(AuthClientExceptionHandler authClientExceptionHandler) {
        this.authClientExceptionHandler = authClientExceptionHandler;
    }

    @Override
    public void configure(ResourceServerSecurityConfigurer resources) {
        resources.resourceId("admin").stateless(true).authenticationEntryPoint(authClientExceptionHandler);
    }

    @Override
    public void configure(HttpSecurity http) throws Exception {
        // 资源链路
        http
                .sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
                // 登录放通
                .and()
                .authorizeRequests()
                .antMatchers("/oauth/**")
                .permitAll()
                // 其他请求都需认证
                .and()
                .authorizeRequests()
                .anyRequest()
                .authenticated()
                // 跨域
                .and()
                .cors()
                // 关闭跨站请求防护
                .and()
                .csrf()
                .disable();
    }

}

3：测试

3.1：先获取token

3.2：携带token访问其他服务的接口

3.3：uml图

认证中心颁发token、对token鉴权，携带token访问其他服务的接口，这是个闭环，合情合理。

4：再聊聊认证中心

每个普通服务一定要配置认证中心的的相关配置吗？答案是否定的。

先看看下面这张图：

当一个请求通过网关的转发之后，其他服务之间还需要通信，当请求到达订单服务，还会通过用户服务、支付服务。
在业务比较复杂的情况下，调用链有可能会更加复杂。
而每个服务都要去认证中心鉴定一下token是否合法，假设每鉴定一次token的耗时为50ms，那么调用链越长耗时更长。

总结：强校验、高耗时。

这种设计几乎是难以容忍的，那么是否可以更好管理token和资源呢？

再看看这张图：

前面就说过了，认证中心除了管理token，理应也具备管理权限、资源的功能，因为服务器之间的调用链可能会非常复杂，
如果每个服务在处理请求之前，都需要去认证中心找一下token是否有效，完全是浪费资源的。
而微服务之间的通信基本是基于内网的，不可能每个服务都暴露在外网，因此我们只需要在统一的入口：网关层 做token、权限资源的校验即可。
这种做法既保证了系统的安全性，也降低了在权限校验上的时间成本。

总结：一次校验、畅通无阻。