SpringCloud-OAuth2（三）：进阶篇
上篇文章讲了SpringCloud OAuth 的实战篇，但是在微服务环境下，常常会有一个认证中心。
而普通服务接收到请求后，判断token是否有效并不是自己处理的，因为token的管理统一交给认证中心，token也理应被认证中心统一管理（职责专一性）。
那么这篇文章会介绍如何搭建认证中心，并介绍普通服务是如何处理token的。
1：认证中心的搭建（OAuth Center）
1.1：回顾
先看下上篇文章：SpringCloud-OAuth2（二）：实战篇
上篇文章其实就已经简单搭建好了一个认证中心，因为我写了一个认证中心的配置。
可以看上文的这部分地方↓↓↓↓↓↓↓↓↓
1.2：我的项目结构图
wfw-auth-center：认证中心
wfw-auth-client：认证客户端
wfw-auth-common：common包
2：认证客户端的配置
只需要做两件事：properties配置、资源服务配置
关于pom：用上篇的或者参考我的github。
为什么需要些资源服务配置？
因为客户端本身是一个服务，需要管理自己资源。但是我们可以将资源交给中心统一管理，这个后面会细说。
2.1：application配置
#认证中心地址
auth.server.address=127.0.0.1:8123
#认证客户端校验token的配置
security.oauth2.client.client-id=admin
security.oauth2.client.client-secret=admin
security.oauth2.client.access-token-uri=http://${auth.server.address}/oauth/token
security.oauth2.resource.jwt.key-uri=http://${auth.server.address}/oauth/token_key
security.oauth2.client.grant-type=password
security.oauth2.client.scope=all
2.2：资源服务配置
参考认证中心的配置做一定的更改即可。
@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、权限资源的校验即可。
这种做法既保证了系统的安全性，也降低了在权限校验上的时间成本。
总结：一次校验、畅通无阻。