8.30 cookie session token jwt

https://mp.weixin.qq.com/s?__biz=MzU2NTc4NjM5OQ==&mid=2247486268&idx=1&sn=195357f0fe2035128e1c0f7db2d6c41b&chksm=fcb7294ccbc0a05aad896949392c406eab08e8bf55e2462aaa7941eea6d4e70100167975652f&mpshare=1&scene=23&srcid=0830CchWlHWx37C5DtiKy9bx&sharer_sharetime=1598765479523&sharer_shareid=e22f24a31ebc3c050a04c9a4e7f37053%23rd

http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

https://www.yuque.com/docs/share/4946bc18-5e16-49a2-9714-024e19dafc93?# 《Web Storage》

1. cookie：

   1. 是什么：因为http协议无状态，每次请求都是独立的所以服务器不能分辨每次请求的发送者是不是同一人，所以为了进行会话跟踪，维护一个状态，能告诉服务器每次请求是同一个人========cookie和session

   2. where：服务器发送到浏览器储存的一小段数据，每次发送请求会被自动携带

   3. 不可以跨域：一级二级域名可以共享 domian

   4. 属性

      1. httponly：设置之后就无法通过js读取到cookie，但是能通过Application手动修改

      2. expires：过期时间-------强缓存第一个方法

      3. domain：cookie所属域名

      4. secure：为true时在http无效，https中才有效，默认false

2. session

   1. 是什么：同上，记录服务器和客户端绘画状态的机制

   2. where：服务端，通过sessionID和cookie联系，sessionID存在cookie中

   3. 过程

      1. 第一次请求，服务端创建session

      2. 返回的时候将session的sessionID发送给浏览器

      3. 浏览器收到这个id存到cookie中

      4. 第二次请求时会判断当前域名的cookie，存在就自动携带发送给服务器，服务器取出id根据id找对应的session找到就成功没有就失败

区别：

1. 存储大小：前者4k，后者访问量太多就会占用很多服务器资源

2. 有效期：前者可设置，后者客户端关闭或者超时就失效

3. 存取值类型：前者--字符串，后者---任意类型

4. 安全性：一个存在客户端一个服务端

 

1. token

   1. 是什么：令牌-----访问资源接口（api）所需要的资源凭证

   2. 组成：uid-用户唯一的身份标识+time-当前时间的时间戳+sign-token 的前几位以哈希算法压缩成的一定长度的十六进制字符串

   3. 流程

      1. 第一次请求username和password，服务器收到后验证name和密码

      2. 验证成功之后签发token，然后返回给浏览器

      3. 浏览器收到就存起来----cookie中或者localstorage

      4. 每个发送请求都携带这个token，然后服务器验证

   4. 注意⚠️：

      1. 每次请求都要携带token，把token放在http的header中中

      2. 基于token的认证是无状态的，用解析token的时间换取存储session的空间，减小服务器的压力和频繁查询数据库的次数

      3. 避开同源策略

   5. 和seesion的区别：

      1. session使服务器有状态，token是服务器无状态

      2. 可以同时使用

   6. Refresh token：用于刷新access 的token

      如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。

2. jwt ------JSON Web Token

   1. 是什么：跨域认证解决方案，认证授权机制

   2. 一般用户认证就是上面的cookiesession流程，但是如果跨域或者服务器集群就要求session共享

      解决方案1---------session数据持久化，各种服务器收到请求就去查找持久层

      解决方案2----服务器不保存session，数据都保存在客户端，每次请求都发给服务器 =>jwt

   3. 原理：服务器认证后生成一个Json对象，每次请求就带上这个对象

   4. 数据结构：包含用户信息

      1. Header（头部）

      2. Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据

      3. Signature 部分是对前两部分的签名，防止数据篡改。

      4. 算法： Base64URL

   5. 使用方式：

      1. 可以存储在cookie：每次请求就自动携带，但是不能跨域

      2. 可以储存在 localStorage

      3. HTTP 请求的头信息Authorization可以跨域

      4. 放在POST请求的数据体 可以跨域

   6. 和token的异同点

      1. 相同点

         1. 都是令牌

         2. 都可以记录用户信息

         3. 都使服务器无状态

         4. 只有成功后才可以访问资源

      2. 区别

         1. token服务器还需要查询数据库，获取用户信息，然后验证 Token 是否有效。

         2. jwt包含了就可以不用或者少量查询数据库

   7. 特点

      1. 默认不加密，可以加密

      2. 不加密不能将重要数据写入jwt

      3. 可以用于认证和交换信息

      4. 一旦签发到期之前始终有效

      5. jwt本身包含认证信息，有效期应该设置短一点

      6. 减少盗用使用https传输

    

常见问题

1. cookie：

   1. 使用 httpOnly 在一定程度上提高安全性

   2. 不要存储敏感数据，比如用户密码，账户余额

   3. 尽量减少 cookie 的体积，能存储的数据量不能超过 4kb

   4. 一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie

   5. 因为存储在客户端，容易被客户端篡改，使用前需要验证合法性

   6. 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

   7. 无法跨域

2. session

   1. 当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session

   2. 当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。

   3. sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？ 一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现

3. token

   1. token 可以避免 CSRF 攻击(因为不需要 cookie 了)

   2.