session && JWT

Sesstion

工作原理

Browser Server POST/authenticate username=...&password=... HTTP 200 OK Set-Cookie: session=...... GET/api/user Cookie: session=... find and deserialize session HTTP 200 OK {name: "foo"} Browser Server

Session 的优势

• 相比 JWT ， 最大的优势就在于可以主动清楚 session 了
• session 保存在服务器端，相对较为安全
• 结合 cookie 使用， 较为灵活， 兼容性较好

Session 的劣势

• cookie + session 在跨域场景表现并不好
• 如果是分布式部署，余姚做多级共享 session 机制
• 基于 cookie 的机制很容易被 CSRF
• 查询 ·session· 信息可能会有数据库查询操作

Session 相关的概念介绍

• session： 主要存放在服务器端， 相对安全
• cookie： 主要存放在客户端， 并且不是很安全

Session 相关的概念介绍

• sessionStorage ： 仅在当前会话下有效， 关闭页面或者浏览器后被清楚
• localstorage: 除非别清楚， 否则永久保存

JWT

什么是JWT？

• 定义了一种紧凑且独立的方式吗可以将各方之间的信息作为JSON对象进行传输
• 该信息可以验证和信任， 因为是经过数字签名的

header

• typ: token的类型， 这里固定为JWT
• alg: 使用过的 hash 算法， 例如： HMAC SHA256 或者 RSA

Payload

• 存储需要传递的信息，如用户ID、 用户名等
• 还包含原数据、如果其时间、发布人等
• 与Header不同， Payload 可以加密

Signature

• 对 Header 和 Payload 部分进行签名
• 保证 Token 在传输的过程中没有被篡改或者损坏

JWT vs Session

可拓展性

随着应用程序的扩大，应用程序人员的增加， 必然要拓展我的程序， 有水平拓展， 垂直拓展， 水平拓展就是加服务器， 垂直拓展就是增加服务器的硬件性能， 比如： 磁盘、内存、cpu等。json数据是存在数据库中的，在水平拓展方案中， 就需要独立的、专门的、中心式的一个session存储系统， 否则session是没办法共享的，存储系统便于所有服务器都可以访问session，共享session， 否则session的缺陷：存储的缺陷无法得到水平拓展。在这种情况下JWT是比session好一些的。因为session是无缝接入水平拓展的，基于token令牌这种校验方式是无状态的

安全性

• XSS攻击： 跨站脚本攻击，JavaScript是可以修改JWT的， 因为JWT是放在cookie sessionstorage中的。
  防范: 签名，加密

• CSRF攻击： 跟cookie相关，只要session或者JWT存在cookie中，就有可能出现跨站请求伪造

• 重放攻击： 要尽量是过期时间短一些

• 中间人攻击： 加了https就好了，在传输过程中是数据是加密的

• RESTful API: rest架构应该是无状态的， 所以session这种有状态的认证方式， 显然是不能用于RESTful API的

性能

• JWT的性能不太好，在客户端发送服务端时， 可能会有大量的用户信息在JWT中，那么每个http请求都会产生大量的开销， 如果是session值会有到少量的开销， 因为session的id非常的小，JWT应为是个JSON，估计会是session的好几倍，
• 但是session存在服务当中的，每次也要通过sessionID在数据库中查看完整的信息，这肯定也是要消耗性能的
  总的来说JWT就是用空间来换时间而session是用时间换空间性能方面各有利弊

时效性

JWT要比session差一些

• 原因： JWT只能等到过期时间进行销毁， 而session存在服务端， 可以手动的去销毁
• 场景1： 若JWT中存储权限相关的信息，当前角色为小管理员，应为滥用管理员权限，就把当前角色权限降级了，但是JWT无法实时更新，必须等到过期才行，不能立即生效。所有当前角色可以乘着还是管理员的时间胡作非为
• 场景2： 用户发现自己的账号在异地被登录了，可能被盗号了。想修改密码来防止盗号，但是JWT没有过期，异地的账号依然可以操作，包括修改密码