Cookie、Session、Token、Authentication、Authorization

Posted 2023-03-15

参考技术A HTTP协议是一种无状态协议,即每次服务端接收到客户端的请求时,都是一个全新的请求,服务器并不知道客户端的历史请求记录,为了解决这个问题就提出了Cookie、Session、Token

Cookie是服务器生成发送到用户浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器发送请求时被携带发送到服务器上.通常它用于告知服务端两个请求是否来自同一浏览器。

用户登录网站的时候,浏览器发出请求,服务器响应请求后,会在响应头里面添加一个Set-Cookie,将Cookie放入到响应请求中,在浏览器第二次发送请求的时候,会通过HTTP请求头将Cookie信息发送给服务器,服务器会辨别用户身份.注意Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定,生成Cookie的内容主要包括：名字，值，过期时间，路径和域.

有两种类型的Cookie

Session是将用户的会话数据存储在服务端，没有大小限制，通过一个session_id进行用户识别

用户向服务器发送用户名和密码,服务器验证通过后会为用户生成一个session,同时为其分配唯一的 sessionId,sessionId就会与这个用户绑定,然后将sessionid通过 cookie传给浏览器,浏览器随后的每一次请求,都会通过Cookie将sessionid 传回服务器,服务器通过session_id验证用户的身份。必须注意的是：Session不一定必须依赖Cookie,也可以放在其他地方比如Authorization或url后面.

客户端登录的时候会将用户信息发送到服务端,服务端对用户信息使用算法以及密钥进行签名,再将这个签名数据作为Token返回给客户端并存储在客户端,客户端后续请求会将Token发送给服务端,服务端验证通过表示用户已登陆就会将请求数据返回给客户端

客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以存储在localStorage中,你可以把它放在 Cookie 里面自动发送,但是这样不能跨域,需要配置,所以更好的做法是放在 HTTP 请求头Authorization字段里面。

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面,JWT是目前最流行的跨域认证解决方案,JWT 解决的最大问题就是Cookie不能跨域.

由于服务器不需要存储 Session 状态，因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期之前就会始终有效，除非服务器部署额外的逻辑。

HTTP www-Authenticate
验证用户身份的凭据(例如用户名/用户id和密码),通过这个凭据系统才知道你是谁,所以Authentication被称为身份/用户凭证

HTTP协议中的Authorization请求头含有服务器用于验证用户代理身份的凭证,通常会在服务器返回401状态码以及WWW-Authenticate小洗头之后在后续请求中发送此消息头

假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为 http://www.bank.com/api/transfer ，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

参考文章:
https://mp.weixin.qq.com/s/DvYIbC-vBOz4teKSLb-K-A
https://blog.mimvp.com/article/39467.html
https://juejin.cn/post/6844903955714015240
https://www.cnblogs.com/cxuanBlog/p/12635842.html
https://segmentfault.com/a/1190000039303557