Cookie、Session、Token、JWT的区别和使用场景

Cookie、Session和Token的区别

	存储位置	数据容量	安全性	生命周期	性能
Cookie	客户端（通常是浏览器）	4KB、Cookie数量也有限制	不安全、XSS（跨站脚本攻击）、CSRF（跨站请求伪造）	可以设置过期时间，过期后自动删除	可能会影响网络传输效率，尤其是在Cookie数据较大时
Session	服务器端	不受数据大小的限制，主要受限于服务器的内存大小	更安全、仍然需要防范Session劫持（通过获取他人的Session ID）和会话固定攻击	可以设置Session的超时时间	这可能会增加服务器的负载，特别是在高并发场景下。
Token	客户端	无需太多存储空间，用CPU加解密的时间换取存储空间	Token机制的安全性依赖于服务端加密算法和密钥的安全性	设置过期时间	Token避免了Session机制带来的海量信息存储问题，也避免了Cookie机制的一些安全性问题，属于典型的时间换空间的思路。

 Cookie通过请求头部发送给服务器：

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookie内部结构： 

Set-Cookie: <cookie名>=<cookie值>HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

Session实现主要两种方式：cookie充当载体与url重写（Cookie禁用）

原始的URL：
http://taobao.com/getitem?name=baymax&action=buy
重写后的URL:
http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy

Token交互流程 

JWT 令牌结构：

第一部分是令牌头（Header）：它描述了令牌的类型（统一为 typ:JWT）以及令牌签名的算法，示例中 HS256 为 HMAC SHA256 算法的缩写，其他各种系统支持的签名。

第二部分是负载（Payload）：这是令牌真正需要向服务端传递的信息。针对认证问题，负载至少应该包含能够告知服务端“这个用户是谁”的信息，针对授权问题，令牌至少应该包含能够告知服务端“这个用户拥有什么角色/权限”的信息。JWT 的负载部分是可以完全自定义的，根据具体要解决的问题不同，设计自己所需要的信息，只是总容量不能太大，毕竟要受到 HTTP Header 大小的限制。

第三部分是签名（Signature）：签名的意思是：使用在对象头中公开的特定签名算法，通过特定的密钥（Secret，由服务器进行保密，不能公开）对前面两部分内容进行加密计算，以例子里使用的 JWT 默认的 HMAC SHA256 算法为例，将通过以下公式产生签名值：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload) , secret)

JWT常见的使用方式是附在名为 Authorization 的 Header 发送给服务端 

GET /restful/products/1 HTTP/1.1
Host: icyfenix.cn
Connection: keep-alive
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hbWUiOiJpY3lmZW5peCIsInNjb3BlIjpbIkFMTCJdLCJleHAiOjE1ODQ5NDg5NDcsImF1dGhvcml0aWVzIjpbIlJPTEVfVVNFUiIsIlJPTEVfQURNSU4iXSwianRpIjoiOWQ3NzU4NmEtM2Y0Zi00Y2JiLTk5MjQtZmUyZjc3ZGZhMzNkIiwiY2xpZW50X2lkIjoiYm9va3N0b3JlX2Zyb250ZW5kIiwidXNlcm5hbWUiOiJpY3lmZW5peCJ9.539WMzbjv63wBtx4ytYYw_Fo1ECG_9vsgAn8bheflL8

JWT的缺点： 

• 令牌难以主动失效：JWT 令牌一旦签发，理论上就和认证服务器再没有什么瓜葛了，在到期之前就会始终有效，除非服务器部署额外的逻辑去处理失效问题，这对某些管理功能的实现是很不利的。譬如一种颇为常见的需求是：要求一个用户只能在一台设备上登录，在 B 设备登录后，之前已经登录过的 A 设备就应该自动退出。如果采用 JWT，就必须设计一个“黑名单”的额外的逻辑，用来把要主动失效的令牌集中存储起来，而无论这个黑名单是实现在 Session、Redis 或者数据库中，都会让服务退化成有状态服务，降低了 JWT 本身的价值，但黑名单在使用 JWT 时依然是很常见的做法，需要维护的黑名单一般是很小的状态量，许多场景中还是有存在价值的。
• 相对更容易遭受重放攻击：首先说明 Cookie-Session 也是有重放攻击问题的，只是因为 Session 中的数据控制在服务端手上，应对重放攻击会相对主动一些。要在 JWT 层面解决重放攻击需要付出比较大的代价，无论是加入全局序列号（HTTPS 协议的思路）、Nonce 字符串（HTTP Digest 验证的思路）、挑战应答码（当下网银动态令牌的思路）、还是缩短令牌有效期强制频繁刷新令牌，在真正应用起来时都很麻烦。真要处理重放攻击，建议的解决方案是在信道层次（譬如启用 HTTPS）上解决，而不提倡在服务层次（譬如在令牌或接口其他参数上增加额外逻辑）上解决。
• 只能携带相当有限的数据：HTTP 协议并没有强制约束 Header 的最大长度，但是，各种服务器、浏览器都会有自己的约束，譬如 Tomcat 就要求 Header 最大不超过 8KB，而在 Nginx 中则默认为 4KB，因此在令牌中存储过多的数据不仅耗费传输带宽，还有额外的出错风险。
• 必须考虑令牌在客户端如何存储：严谨地说，这个并不是 JWT 的问题而是系统设计的问题。如果授权之后，操作完关掉浏览器就结束了，那把令牌放到内存里面，压根不考虑持久化才是最理想的方案。但并不是谁都能忍受一个网站关闭之后下次就一定强制要重新登录的。这样的话，想想客户端该把令牌存放到哪里？Cookie？localStorage？Indexed DB？它们都有泄漏的可能，而令牌一旦泄漏，别人就可以冒充用户的身份做任何事情。