一些关键词: 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 功能, 客户端可以修改
- 缺点: 灵活意味着事儿也多
| 跨域 | 单点登录 | 设置 httpOnly | 请求携带 | 存储容量 | |
|---|---|---|---|---|---|
| cookie | 不能 | 不能 | 可以 httpOnly, 相对更安全 | 必须携带 | cookie 5bk |
| request headers | 可以 | 可以 | 不能 httpOnly, 相对有危险 | 可以判断 | 若放在 sessionStorage 上限为 5mb |
问题: 登录解决方案 session VS jwt:
session 与 jwt 本身都是密匙, 都存放着某些敏感信息, 都需要设置过期时间, 不同的是
session:
- sessionId 本身是一个密匙, 是通过服务端动态生成的
- sessionId 本身不带有 用户信息, 需要用 sessionId 跑到 redis 里拿到 userInfo
- session 对象是通过服务端管理的, 一般都放在 redis 里
- 关于单点登录方面, 放在 cookie 里不能实现, 放在 request headers 可以实现
- session 本身依赖 redis 管理, 所以可以在服务端操作用户登录状态
- 业内公认 可拓展性 jwt 比 session 好, 因为 jwt 本身就携带 userInfo 信息, 可以在不同的域名里传递.
- session 安全性高, 因为 sessionId 在客户端存的内容比 jwt 少, 且 sessionId 一般存在 cookie 里, cookie 可以设置 httpOnly. jwt 一般存在 sessionStorage 里, 客户端可以修改
- RESTful 规范要求 请求无状态 规范, jwt 要本身就是无状态的
- session 请求携带量小, 但每次请求都携带, 之后还要去 redis 里去查 userInfo. jwt 请求携带量大, request 后不需要再去 redis 里查找, 本身就是 userInfo, 用空间换时间.
- 时效性应用场景: 用户在系统中滥用权限, 管理员对用户降级处理. 账号在异地登录, 使账号强制登出. 这些场景 session 比 jwt 好用.
jwt( json web token ):
- jwt 本身是一个密匙, 是通过服务端加密算出的
- jwt 本身就携带 用户信息, 所以不需要用到 redis
- token 字符串里包含所有的 用户信息, 不需要 redis, 所以服务端也很难管理( 如: 强制登出某用户, 若用黑名单实现需要记录此用户的下次请求动作 )
- 关于单点登录方面, 放在 cookie 里不能实现, 放在 request headers 可以实现
- jwt 不需要 redis, 在服务端管理比较难
| 密匙信息 | 在客户端的字符串 | redis依赖 | 单点登录 | 服务端管理 | 可拓展性 | 安全性 | RESTful | 性能 | 时效性 | |
|---|---|---|---|---|---|---|---|---|---|---|
| session | sessionId 就是一个动态生成的临时 key | 不是一层不便的 | 依赖 | 能实现 | 相对好管理 | 良 | 优 | 语法上也能实现 | 优 | 优 |
| jwt | token 包含所有用户信息 | 不是一层不便的 | 不依赖 | 能实现 | 相对难管理 | 优 | 良 | 支持无状态规范 | 良 | 良 |
