网站安全认证框架演进

单块阶段

V1 版本

1. 用户输入用户名和密码登录 Web 服务器
2. 服务器接收到用户名和密码信息去数据库中查找该用户
3. 在内存中维护一个 sessionId<>User信息 的映射表，这个记录是有时间限制的，长时间不更新会被清除掉，并将 sessionId 传给浏览器端
4. 浏览器端使用 cookie 来存储 sessionId
5. 后续通过浏览器访问时，浏览器会将 cookie 中的 sessionId 发送给服务器端
6. 服务器在映射表中比对，提取出用户相关的信息进行下一步的操作
   1. 如果匹配不上，那么说明会话超时，会提醒用户重新登录
   2. 每次登录都会刷新映射表信息
   3. 如果主动退出或者会话超时，都会删除映射表中对应的项

      V1.1 版本

      
      当引入 Web 服务器集群，会出现用户间歇性地退出登录的问题。因为用户信息存在某台机器上，如果请求打到另外的机器上就查询不到了。
      针对这个问题，引入“粘性会话”机制，将会话信息“粘”在某台机器上，所有的会话相关请求都统一处理，Nginx 是支持该功能的，配置一下就好了。

随着业务发展和规模扩大，“粘性会话”出现了问题。

1. 如果对“粘性会话”绑定的服务器进行升级部署，服务器本身会出现延迟或者宕机，那么对应的一波用户会话会瞬间消失，必须重新登录
2. 有状态服务器，难以扩展

常见解决方案：

1. 会话同步复制：每个服务器的会话数据都会实时同步到其他机器上，整个集群需要引入复杂的状态同步协议，整体性能下降

2. 无状态会话：会话信息不存在服务器上，而是存在用户的浏览器上，但是有泄漏风险，且有大小限制

   V1.5 版本

   
   采用集中会话存储的方式，把会话信息放在 redis 中，服务器本身不需要存储会话信息，有会话请求时，直接通过 sessionId 到集中存储中获取

   微服务阶段

   微服务架构开始兴起，应用的形态变得更加多样化，服务开始解耦拆分，以应对更加多样化的用户。微服务架构给安全认证带来了新的挑战：

3. 后台应用和服务众多，如何统一进行鉴权

4. 前端体验众多，不可能每种前端都搞一个登录认证
5. 需要单点登录（SSO）

将登录认证抽取成一个单独服务，这个服务统一进行登录认证，会话管理，令牌颁发，校验等职责。

1. 用户通过某种客户端，输入用户名密码进行登录
2. Auth Service 通过查询后台数据库，校验用户名和密码。
3. 如果校验通过，则建立一个会话 Session
4. 认证后 Auth Service 返回 token 给客户端，客户端临时存储 token
5. 客户端向后端发送请求会带上 token
6. 微服务接收到带 token 的请求，需要向 Auth Service 校验该 token，在微服务中任何需要用到用户信息的场景都可以通过 token 去查询
7. 调用完成，响应返回给客户端

流程中的令牌相当于在线 ID，每个服务都能通过令牌完成认证鉴权操作
如果令牌的认证鉴权过程散落在各个微服务之间，容易造成不规范，遗漏认证等问题，正好要引入微服务网关，所以就把认证鉴权逻辑移到网关去做

这种架构的缺点在于，如果服务的流量比较大，Auth Service 承担的压力也就比较大，可能成为总体的瓶颈。

引入 JWT 令牌，大幅简化架构，降低 Auth Service 的访问压力，适合于安全校验不太敏感的系统。

JWT 原理

JWT 令牌结构

Json Web Token，是一种数据结构标准，通过它可以在多个系统间安全地校验信息。

认证流程

其中的 Resource Server 可以当做微服务的另一种称谓。Auth Server 和 Resource Server 需要提前商定好一个签名和解签的 secret。

1. 客户端向 AS 发送登录请求
2. AS 生成 JWT 数据结构，并且进行签名，将签名的 JWT 发回客户端，客户端收到后进行本地的存储
3. 客户端向 RS 发出 API 调用的请求，RS 取出 JWT 令牌，采用同样的 secret，对请求进行校验
4. 返回响应给客户端

RSA 流程改用公钥和私钥进行签名和解签，更安全，过程类似非对称加密

JWT 优劣