javaweb：无状态和有状态的两种不同认证方式

两种认证简介

1. 有状态认证

       有状态认证， 以cookie-session模型为例， 当客户端第一次请求服务端的时候， 服务端会返回客户端一个唯一的标识（ 默认在cookie中） ， 并保存对应的客户端信息至sessionManager中。
       客户端接受到唯一标识之后， 将标识保存到本地cookie中， 以后的每次请求都携带此cookie， 服务器根据此cookie标识就可以判断请求的用户是谁， 然后查到对应用户的信息。
       如果session过期或者手动删除服务端的session信息， 该用户请求将会失去认证， 需要重新登录保存session才可以再次请求受保护的资源。

2. 无状态认证

       无状态认证， 以json-web-token为例， 客户端在提交身份信息， 服务端验证身份后， 根据一定的算法生成一个token令牌返回给客户端， 但服务端本身并不保存token， 这样原生就支持了分布式的特性， 无需在每台服务器都做同步。
       客户端接受到token后， 会将令牌保存到本地， 之后每次请求服务端， 客户端都需要携带此令牌， 服务器接受到令牌进行校验， 校验通过， 以解析令牌的信息用来区别用户。

两种认证优劣

1. 有状态认证

1.1优势

       因为客户端的信息都保存在服务端的 Session Manager 中， 如果要将客户端的认证信息取消， 只需要将对应的session 信息删除即可， 及时响应， 方便快捷。

1.2劣势

       服务端保存着客户端的信息， 当用户量特别多时候， 服务端需要特别的内存资源； 客户端的信息在服务端中维护， 如果服务端为集群的场景下， 那么客户端信息不共享， 必须使用分布式 session 或者其他方案； cookie有同源策略和跨域限制， 部分业务场景下cookie并不能传递； 部分设备本身不支持cookie或者禁用cookie， 还有的手机浏览器也不支持cookie。

2. 无状态认证

2.1优势

       因为服务端不保留客户端的任何信息， 每次只需要通过特定的算法进行校验， 节省了大量存储空间；方便水平扩容， 不需要拓展服务器， 也不需要进行信息同步， 只要保证新的应用采用同样的验证算法， 就可以验证通过并获得对应信息。

2.2劣势

       当客户端的token被盗用， 或者需要手动封禁某个用户的时候， 没办法对此token进行操作， 必须等待
token失效。