安全认证架构演进：微服务阶段

Hi，我是阿昌，今天学习记录的是关于安全认证架构演进：微服务阶段的内容。

在上一篇：《安全认证架构演进：单块阶段》讲了针对单块服务阶段的安全认证架构发展演技过程，到现在的微服务阶段;

在不同的阶段会有不同阶段的问题，微服务阶段也是一样。

一、微服务认证鉴权挑战

因为业务的形态发生了多样化，出现了各式各样的，如WebMVC引用、无线应用、前后分离H5应用等，那就需要改造认证鉴权的方式，让它是支持上面出现各式各样的引用。

那如上出现了许多的挑战：

1. 后台引用和服务众多，如何对每一个服务和引用鉴权
2. 前端的用户引用众多，针对每一个引用都需要搞一套独立的鉴权方案，成本和开发时间过大
3. 需要考虑SSO单点登录，减少用户的重复登录操作

二、2.0阶段

上面的分析得出的结果，之前的1.5阶段基于session&cookies的方式需要被改变，不能沿用，但是可以借鉴其思想，进一步的延伸改造，并可以针对微服务的场景进行针对扩展。

2.0阶段最大的变化是将登录认证鉴权的逻辑抽取成了独立的一个专门的auth service服务来进行处理，它这个服务统一处理登录认证、令牌颁发、会话管理校验等职责；另外2.0阶段也引入了Token令牌的服务调用校验健全的主要机制。

在2.0阶段中采用“透明令牌”：令牌是一个无异议的随机字符串，当是这个令牌和一次登录的会话是相关联的，后续可以通过这个透明令牌去鉴权服务专门的校验权限，或查询对应用户的数据信息，所以这个令牌又可以成为“引用令牌”，它本身不包含数据，它是鉴权服务上用户信息引用的一个标识符，类似与之的sessionId。

1. 用户登录会统一走鉴权服务authService统一完成，用户通过某个客户端。 输入用户密码登录，请求鉴权服务authService处理。authService查询数据，如果通过校验，这建立一个用户会话session，存在过期的时间，可以存放到数据库中，也可以存储在redis缓存中
2. authService成功会返回Token给客户端，客户端可临时存储这个Token令牌。
3. 客户端向后端微服务发出请求，这个请求会带上本地存储的Token令牌，携带的方式可以在HttpHeader等上。
4. 微服务接收到客户端发来的请求，并获取到客户端发来的Token令牌，微服务会发起请求到authService校验服务去校验客户端发来的Token令牌是否能通过校验。
5. 在后续微服务需要用到用户信息时，微服务可以用Token令牌去向authService鉴权服务去获取对应Token令牌对应的用户信息。
6. 调用完成，响应返回客户端。

2.0阶段类似1.5阶段中集中状态会话方案的改造和扩展，它将用户鉴权认证授权颁发Token令牌都统统封装到了统一的服务authService当中，使的职责跟清晰；且引入的令牌的机制，可以做到SSO单点登录机制。

但是也存在一定的问题，如每个微服务都需要写一些认证鉴权的逻辑，使得对应业务的开发方也需要写对应的鉴权逻辑，增加的开发成本；另外将认证鉴权逻辑分散开，会具有用户信息安全的风险；也存在开发不够规范。

三、2.5阶段

为了解决上面的一些问题，2.5阶段引入了网关模块，他在微服务调用之前进行做调用的分发和代理。

2.5阶段与上面的2.0阶段大致相同，唯一不同的增加了网关的模版。

因为引入了网关作为微服务的入口，那网关就可以统一的去authService上去做健全和认证对其Token令牌进行校验。
网关向authService服务去用Token令牌可以获取到用户信息，后续可以将用户信息直接去通过调用传递给后面的微服务。
后台的微服务可以直接通过网关获取用户的信息，后台的网关和微服务之间是相互信任的，所以微服务自己直接是不需要再重复的去authService去鉴权和认证。

通过引入网关做统一的认证鉴权后，大大简化了后台微服务开发方，让他们只针对开发后台的业务逻辑，并不需要去担心用户鉴权的内容，这样子就开发会更加的规范，且更简单；