项目 用户认证调研与可行性方案分析
参考资料： JWT JWT认证方案实施1 JWT认证方案实施2 EGG中JWT实施方案 EGG-SESSION
Cookie存储在浏览器端，Session存储在服务端。
注意：客户端中只有浏览器存在cookie
- 用户录入信息登录
- 服务端验证后，创建session信息，并将sessionID存储到cookie，发送回浏览器
- 浏览器端再次发送请求时，自动带上cookie信息，服务端通过cookie中存储的sessionID获取session进行验证
- 只能在web场景中使用
- cookie不能跨域
- 存在CSRF风险 -分布式系统，需考虑session的同步问题
浏览器端不再使用cookie，如：web使用localStorage， app使用客户端数据库。实现多客户端使用，解决跨域问题，并避免了CSRF。服务端不再使用session。
- 用户录入信息登录
- 服务端验证后，将用户认证信息存储到redis，并返回相应key
- 客户端接收到返回信息后，将key存储在本地
- 客户端再次发送请求时，在header带上key，服务端key获取redis中的认证信息进行验证
- 用户录入信息登录
- 服务端验证后，将用户认证信息进行加密生成token，并返回给客户端
- 客户端接收到返回信息后，将token存储在本地
- 客户端再次发送请求时，在header带上token，服务端验证token
问： ctx.session.user = user 具体做了什么事？
- 用户录入信息登录
- 服务端验证后，设置
ctx.session.user = user - egg: 将session的value信息进行加密，存储在cookie的EGG-SESS字段中，发送回浏览器
- 客户端再次发送请求时，header中自动带上cookie，egg验证EGG-SESS
总结：
| 方案 | 传统方案 | 借助redis存储 | JWT token方案 | EGG.js方案 |
|---|---|---|---|---|
| 核心技术 | cookie + session | redis存储 | 加密算法 | cookie + session |
| 客户端支持 | 仅支持web | 全部支持 | 全部支持 | 仅支持web |
| 安全性 | 有风险 | 安全 | 安全 | 安全 |
| node 多进程、多服务的影响 | 受影响，可能出现session不同步 | 不影响 | 不影响 | 不影响 |
对于node语言，在不考虑多端的情况下，可直接使用EGG.js方案。 对于其他后端语言，建议使用JWT token方案。