1、Cookie

cookie 的起源是购物车，服务器不想记录购物车信息，于是想把记录工作交给浏览器。

1.1、工作机制

服务器维护着cookie，客户端（浏览器）存储着cookie。客户端会无条件的存储服务端发来的cookie，下次请求服务端时再把保存的cookie带过去。

sequenceDiagram
服务端 xx.com ->>客户端:给你一个 cookie
客户端->>客户端: 保存 xx.com - cookie
客户端 --)服务端 xx.com: 请求 xx.com 把 cookie 携带过去

1.2、作用

会话管理：登录状态、购物车
个性化：用户偏好、主题
Tracking：分析用户行为
XSS（Cross-site scripting）：HttpOnly

HttpOnly：设置cookie时添加HttpOnly，本地脚本就看不到cookie。保存敏感信息
XSRF（Cross-site request forgery）：Referer

Referer：判断从哪个网站跳转过来的，依赖浏览器工作。a网站跳转b网站，浏览器会加 Referer

1.3、使用 cookie 管理登录状态

sequenceDiagram
客户端 ->>服务端: username=01&password=123
服务端 ->>服务端: username=01登录了，生成一个session_id=abc
服务端 --)客户端: 让客户端保存Cookie： session_id=abc
客户端 ->>服务端: 请求携带 Cookie:session_id=abc
服务端 ->>服务端:校验 Cookie 中的 session_id，状态是已登录受理请求

2、Authorization

2.1、Basic

Authorization:Basic<base64(username&password)>

对用户名密码Base64后就是认证信息

安全性交给https，因此不用担心在传输过程中泄密，但是basic token是存本地的。客户端root后还是可能存在风险

2.2、Bearer

Authorization:Bearer<bearer token>

认证信息需要授权方给你，而不是自己生成。即客户端不持有token

2.2.1、OAuth2（授权）

比如我是Github用户，我要将权限授予掘金这个网站

第一方是我
第二方是Github（授权方）
第三方是掘金

最终目的是用户（我）将授权方网站（github）的用户认证信息access token给予第三方（掘金）

绘图1.png

2.2.2、微信登录（登录）

参考微信文档，与OAuth2大同小异

2.3.3、refreshToken

授权方同时返回access-token和refresh-token，当access-token 失效后，用refresh-token来刷新获取新的acees-token

登录与授权