安全认证架构演进：单块阶段
Hi，我是阿昌，今天学习记录的是关于安全认证架构演进：单块阶段的内容。
讲到安全认证的内容，就必然会提到两个点：认证 和 授权。
- 认证：我是谁
- 授权：我能做什么
一、1.0阶段
参考图如下：
- 用户在浏览器上输入账号密码，请求对于到Web服务器
- 服务器服务器到认证过滤器会处理，拿着对应用户的信息去数据库查询
- 如果存在，将用户的信息数据写入到session中做服务器端缓存并正常处理业务逻辑，最后返回，并将sessionId写入浏览器cookies中做临时客户端储存
- 如果不存在，直接返回，要求用户重新登陆
- 每次用户登陆都会刷新session上的活跃时间来持续储存来保证不会删除。
- 当用户退出登陆，就在session上删除该用户对应的记录
对应的session储存方案，走sessionId + 用户信息的方式，相当于一个hashmap，当这个map中找不到或因为存在时间过期了，就会出现会话超时的情况。
session中不仅可以只存储用户的基本信息，也可以存储用户的其他会话信息，比如购物车信息等，相当于用户信息数据的临时存储。
二、1.5阶段
针对上面的1.0版本存在一些列的缺陷， 当web服务器采用集群的时候，会出现困难因负载均衡造成session在只在登陆过的web服务器中存在；
下图给出了一个解决1.0阶段的方案：StickySession粘性会话
在反向代理层做一个sessionId与对应web服务器的映射关系信息，每次当请求在反向代理层根据对应的sessionId来路由到对应的web服务器中，保证一个会话期间，用户请求和对应的web服务器的一一对应的。
1.1阶段出现的问题，稳定性问题，因为粘性会话到导致用户sessionId跟web服务器进行绑定，当web服务器发生宕机或软件代码升级的场景时，会出现一批量用户出现会话过期的情况，就会造成用户体验不好
解决1.1阶段出现的问题的方案：
- 会话同步复制：让web服务器集群间进行session会话的相互复制
- 无状态会话：将session的数据直接储存在客户端的浏览器中，通过请求响应循环捎带，但这样子存储用户信息在浏览器中会存在用户数据泄漏的风险，所以一般大概率的都会对这个存储的数据进行加密保存；另外浏览器cookies储存的数据大小是有限制的，只有4k大小，不能储存较大的用户数据
- 集中状态会话：把session数据进行集中存储到某个用户鉴权中心（如redis、mysql等）
三、总结
一个网络系统中，认证和授权是十分重要的环节，他告诉了这次请求的用户是谁，他有什么权限，他能不能做这个操作的校验；
- 在一个开始的1.0方案中是一台web服务器，可直接存储在服务器和客户端的Session&cookies的方式进行直接储存；
- 在1.1方案中因为web服务器升级为了集群的方案，不能通过单台服务器的session&cookies的方案储存，可使用下面的方案进行解决：
- 会话同步复制
- 无状态会话
- 集中状态会话
