## 两种认证简介 ### 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失效。