登录方案session VS jwt 对比

一些关键词: cookie / request / headers / session / jwt / token / sessionStorage

问题: 客户端把登录密匙( sessionId 或 jwt )放在 cookie VS request headers 里:

cookie 与 request headers, 本身都是 request 请求的信息载体

1. 放 cookie 里:

• 缺点: cookie 本身有存储容量上限小 5kb,
• 缺点: 每次 request 请求都携带 cookie,
• 缺点: cookie 不能跨域名, 不能实现点单登录
• 优点: 服务端通过设置 httpOnly 客户端不可以修改密匙
• 优点: 想的少, 放里就完了, 请求每次都携带

2. 放 request headers 里:

• 优点: 如果存在 sessionStorage 里, 容量上限 5mb,
• 优点: 每次 request 请求可以判断是否携带,
• 优点: 可以跨域名, 可以实现点单登录
• 缺点: 无 httpOnly 功能, 客户端可以修改
• 缺点: 灵活意味着事儿也多

问题: 登录解决方案 session VS jwt:

session 与 jwt 本身都是密匙, 都存放着某些敏感信息, 都需要设置过期时间, 不同的是

session:

1. sessionId 本身是一个密匙, 是通过服务端动态生成的
2. sessionId 本身不带有 用户信息, 需要用 sessionId 跑到 redis 里拿到 userInfo
3. session 对象是通过服务端管理的, 一般都放在 redis 里
4. 关于单点登录方面, 放在 cookie 里不能实现, 放在 request headers 可以实现
5. session 本身依赖 redis 管理, 所以可以在服务端操作用户登录状态
6. 业内公认 可拓展性 jwt 比 session 好, 因为 jwt 本身就携带 userInfo 信息, 可以在不同的域名里传递.
7. session 安全性高, 因为 sessionId 在客户端存的内容比 jwt 少, 且 sessionId 一般存在 cookie 里, cookie 可以设置 httpOnly. jwt 一般存在 sessionStorage 里, 客户端可以修改
8. RESTful 规范要求 请求无状态 规范, jwt 要本身就是无状态的
9. session 请求携带量小, 但每次请求都携带, 之后还要去 redis 里去查 userInfo. jwt 请求携带量大, request 后不需要再去 redis 里查找, 本身就是 userInfo, 用空间换时间.
10. 时效性应用场景: 用户在系统中滥用权限, 管理员对用户降级处理. 账号在异地登录, 使账号强制登出. 这些场景 session 比 jwt 好用.

jwt( json web token ):

1. jwt 本身是一个密匙, 是通过服务端加密算出的
2. jwt 本身就携带 用户信息, 所以不需要用到 redis
3. token 字符串里包含所有的 用户信息, 不需要 redis, 所以服务端也很难管理( 如: 强制登出某用户, 若用黑名单实现需要记录此用户的下次请求动作 )
4. 关于单点登录方面, 放在 cookie 里不能实现, 放在 request headers 可以实现
5. jwt 不需要 redis, 在服务端管理比较难