Cookie，Session，Token and Oauth
- 2020 年 1 月 22 日
- 筆記
Cookie
服务器端生成，发送给客户端，保存用户信息。下一次请求同一网站时会把该cookie发送给服务器。
应用：登录表单自动填充，同样
随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等。马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放商品， 也就是说我必须把每个人区分开。
session id
想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了。
问题：
- 每个人只需要保存自己的session id，而服务器要保存所有人的session id （存储问题）
- 服务器扩展能力受限，两个服务器组集群的时候，session需要复制 【session单独部署一台服务器，又会导致单点故障问题，部署集群在成本上花费太多】
Token
token本质是用CPU的计算时间换取session的存储空间。
Token验证流程：
小A登录系统，服务器向客户端发送一个令牌（Token），Token的形成过程：将user id ，密钥，通过HMAC-SHA256 算法，生成签名，将签名和数据一起作为Token。
当小A再次发送请求时，请求头就会带有Token，服务器对user id和密钥再次进行计算，和签名比较，验证用户身份。
在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。 大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
Token特性：
•无状态、可扩展
•支持移动设备
•跨程序调用
•安全
JWT——Token的实现
JWT：JSON Web Token
包含三个部分
- header：描述JWT元数据，定义生成签名算法以及Token类型
- Payload（负载）：存放需要传递的数据
- Signature：服务器通过
Payload、Header和一个密钥(secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成
常见问题
用户修改密码后Token更新问题
使用 用户的密码的哈希值对 token 进行签名。因此，如果密码更改，则任何先前的令牌将自动无法验证。
OAuth2.0
OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用，获取用户数据。
(应用中集成第三方登录，微信，QQ，微博等等)
四种授权方式：
- 授权码（authorization-code）
- 隐藏式（implicit）
- 密码式（password）：
- 客户端凭证（client credentials）
参考文档：
