前言
权限管理和令牌认证是一个系统最基本的功能，在以往的方案中，最常见的方案是把信息保存至 session 中实现有状态认证。随着微服务的兴起，一种新的认证方法又火了起来，那就是JWT，采用了无状态认证。
两种认证简介
1. 有状态认证
- 有状态认证，以cookie-session模型为例，当客户端第一次请求服务端的时候，服务端会返回客户端一个唯一的标识（默认在cookie中），并保存对应的客户端信息至sessionManager中。
- 客户端接受到唯一标识之后，将标识保存到本地cookie中，以后的每次请求都携带此cookie，服务器根据此cookie标识就可以判断请求的用户是谁，然后查到对应用户的信息。
- 如果session过期或者手动删除服务端的session信息，该用户请求将会失去认证，需要重新登录保存session才可以再次请求受保护的资源
2. 无状态认证
- 无状态认证，以json-web-token为例，客户端在提交身份信息，服务端验证身份后，根据一定的算法生成一个token令牌返回给客户端，但服务端本身并不保存token，这样原生就支持了分布式的特性，无需在每台服务器都做同步。
- 客户端接受到token后，会将令牌保存到本地，之后每次请求服务端，客户端都需要携带此令牌，服务器接受到令牌进行校验，校验通过，以解析令牌的信息用来区别用户。
两种认证优劣
1. 有状态认证
- 优势：因为客户端的信息都保存在服务端的 Session Manager 中，如果要将客户端的认证信息取消，只需要将对应的session 信息删除即可，及时响应，方便快捷。
- 劣势：服务端保存着客户端的信息，当用户量特别多时候，服务端需要特别的内存资源；客户端的信息在服务端中维护，如果服务端为集群的场景下，那么客户端信息不共享，必须使用分布式 session 或者其他方案；cookie有同源策略和跨域限制，部分业务场景下cookie并不能传递；部分设备本身不支持cookie或者禁用cookie，还有的手机浏览器也不支持cookie。
2. 无状态认证
- 优势：因为服务端不保留客户端的任何信息，每次只需要通过特定的算法进行校验，节省了大量存储空间；方便水平扩容，不需要拓展服务器，也不需要进行信息同步，只要保证新的应用采用同样的验证算法，就可以验证通过并获得对应信息。
- 劣势：当客户端的token被盗用，或者需要手动封禁某个用户的时候，没办法对此token进行操作，必须等待token失效。
后记
- BladeX 经过精心设计与长期稳定的线上生产，已经将两种认证模式相互结合，优缺点互补，尽最大努力提升性能与安全性
- 用户可以灵活选择无状态认证或者经过增强后的有状态认证模式
- 有状态认证模式解决了以往方案的大部分劣势，将其转换为优势，补足了无状态认证的短板，使其更加安全。