[TOC] ## 一、无网络隔离是指用户访问的网络环境与整个系统的部署网络环境是相通的,例如用户可以绕过API网关直接访问后台的服务 ### 1 架构图 #### 1.1 JWT ![](https://img.kancloud.cn/0c/d7/0cd7e51bbeae84ed97791448c81894c8_1083x607.png) #### 1.2 Redis ![](https://img.kancloud.cn/d5/14/d514c70426107acef9e163169378aebf_1017x647.png) ### 2 设计思路 * **统一认证**:负责登录认证、token派发、token刷新、应用接入管理等功能 * **API网关**:只负责路由转发 * **微服务**:每个服务都需加入认证中心的sdk负责所有请求的鉴权 * **TokenResolver**:嵌入在微服务程序中通过SecurityContextHolder获取当前登录人,主要原理如下: 1. 判断当前url请求的方法有没有带有`@LoginUser`注解 2. 判断`@LoginUser`注解的`isFull`属性是否为`true`则通过`username`查询用户对象 3. 构建`SysUser`对象传给目标方法 ## 二、无网络隔离的情况下需要保证每个服务的API访问都要进行认证 ### 1 架构图 ![](https://img.kancloud.cn/98/e8/98e8d7d0b1afb4b7f88b09cb19a97096_1583x946.png) ### 2 设计思路 在V1的架构基础上进行改进保证每个服务的API都有认证,并且客户端与服务内部分别使用不同的token同时融合了redisToken和jwt两者的优点 1. 客户端使用redisToken * **减少网络带宽消耗**:普通的uuid token对于jwt的长度小很多 * **能实现更多的功能**:使用redisToken功能更多,能方便实现如token自动续约、在线用户列表、踢人等功能 2. 内部服务使用jwt * **场景符合**:由于是内部服务使用,客户端只能获取access token没有jwt,所以无需让jwt token失效符合jwt特性 * **提升性能**:服务与服务之间的通信只需通过jwt自解析认证,无需网络连接,大大减少redis的压力和提升性能 * **增加安全性**:内部服务与客户端所使用的token不一样,能有效防止客户端绕开网关直接请求后面服务 ### 3 实践思路 1. 自己实现一个`RedisTokenStore`在`storeAccessToken`的时候使用私钥生成`JWT`并存到`Redis`中 2. 网关添加过滤器在认证`access_token`成功后,获取`JWT`存到`header`中请求后面的内部服务 3. 每个内部服务都添加`@EnableResourceServer`配置为资源服务器,并且`pigframe.oauth2.token.store`设置为`resJwt`使用公钥自解析`JWT`