cookie
Web Application一般使用HTTP协议作为信息传输协议，但是HTTP协议是无状态的，也就是说一次HTTP成功断开后(HTTP协议为一次请求一次响应)，这个时候如果客户端再次发送请求，服务端则不能辨识这个客户端为上次刚刚发起请求过的客户端，这就说明HTTP协议不能支持会话跟踪，这个时候cookie的出现，实现了HTTP的会话跟踪。
简单地来说，cookie就是服务端发放给客户端的一账通行证，并且通过这张通行证(cookie)来进行身份的辨识。本质上cookie是一小段文本信息，包含有如user_session/logged_in等可以标识用户以及可以表示用户的状态的一些字段
可以看到在登陆之后存在的比较关键的两个字段logged_in（状态显示yes已登录）user_session是一串会话的标识，这两个字段基本就能在标识一个用户的同时还能标识这个用户的状态
可以看到标识的
logged_in字段的值已经变成no，表示当前没有用户登录github并且也没有了
user_session这个字段，因为也没有必要为一个没有登录的用户分发一个辨识会话的
session
session
基于 session 的用户认证借助于请求体对象 req 中的 session 数据来完成.
//基于WebServlet3.0的获取session的方式
//这种方式获取session如果本次会话存在，则返回本次会话session
//如果不存在则创建一个新的session
HttpSession session = request.getSession();
session在访问tomcat服务器HttpServletRequest的getSession(true)的时候创建，tomcat的ManagerBase类提供创建sessionid的方法：随机数+时间+jvmid。
当客户端请求服务端经过身份验证之后，服务端会生成并且保存身份信息相关的session数据，并且将对应sessionid写入cookie，通过响应传输给客户端，客户端将cookie保存在本地，以便第二次或以后的请求能够带上cookie中的sessionid去让服务端辨识该用户是属于哪个会话的(tomcat生成的sessionid叫做jsessionid)，并且也会验证cookie字段中的logged_in字段，判断这个字段是因为，如果该用户是经过验证的，则这个字段的值肯定为(yes,true,1)这时，就无需重新认证身份，否则，需要重新进入身份认证流程。
session缺点
- tomcat的StandardManager类将session存储在内存中，也可以持久化到file，数据库，memcache，redis等。客户端只保存sessionid到cookie中，而不会保存session，session销毁只能通过invalidate或超时，关掉浏览器并不会关闭session。
- 正如上面提到的那样，tomcat这种web服务器默认是将session存储在内存中，自己写的项目因为没有对session进行超时处理有好几次是因为session数量过多导致服务端的崩溃需要重新开启，所以今后在处理session保存会话信息的时候要额外注意
- 如果原生 App 不具备 cookie 功能模块, 就会加大其接入 session 认证后端的难度(写过几个基于session认证的App的后端，客户端如果需要进行session的认证，每次请求就要手动携带上从我这里返回的cookie)
简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证
token
token也称作令牌，由uid+time+sign[+固定参数]组成:
- uid: 用户唯一身份标识
- time: 当前时间的时间戳
- sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
- 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库
以下几点特性会让你在程序中使用基于Token的身份验证
- 无状态、可扩展
- 支持移动设备
- 跨程序调用
- 安全
由其组成可以看出, token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据,
token 只被保存在客户端 中的cookie 或 localstorage(数据库).
因为用户的状态在服务端的内存中是不存储的，所以这是一种无状态的认证机制。
token的认证流程
- 用户登录校验，校验成功后就返回Token给客户端。
- 客户端收到数据后保存在客户端
- 客户端每次访问API是携带Token到服务器端。
- 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
缺点:
因为 token 一般都是 hash/encrypt 的字符串, 所以会额外附加 加密/解密 的性能开销
有些加密方式同样存在安全隐患
推荐一篇讲解JWT优缺点的帖子 https://www.jianshu.com/p/af8360b83a9f
