cookie session token 使用和区别

Question

session

存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号 sessionId，通常存放于 cookie 中。服务器收到 cookie 后解析出 sessionId，再去 session 列表中查找，才能找到相应 session。依赖 cookie

cookie

类似一个令牌，装有 sessionId，存储在客户端，浏览器通常会自动添加。
举例：服务员看你的身份证，给你一个编号，以后，进行任何操作，都出示编号后服务员去看查你是谁。
浏览器自动携带

前端发送 cookie 操作

• 链接
• 预加载
• get 表单
• post 表单
• iframe
• image
• ajax
• script

怎么禁止 JS 访问 cookie（httponly）

https://zhuanlan.zhihu.com/p/36197012
https://blog.csdn.net/qq_38553333/article/details/80055521
https://www.jianshu.com/p/ba6500990694

token

也类似一个令牌，无状态，用户信息都被加密到 token 中，服务器收到 token 后解密就可知道是哪个用户。需要开发者手动添加。
举例：直接给服务员看自己身份证
浏览器不会自动携带

jwt

JSON Web Token
只是一个跨域认证的方案

Cookie 通过在客户端记录信息确定用户身份
Session 通过在服务器端记录信息确定用户身份

如果浏览器禁止了 cookie 怎么办？

每次请求都携带一个 SessionID 的参数；或者使用 token 令牌，登录后服务端生成一个 Token 返回给客户端，以后客户端携带 token 进行数据请求。
缺点：容易被劫取

前后端实现登录的方式有哪些？

• cookie + session：前端登录后，后端会种一个 httpOnly 的 cookie 在前端，里面就有这个用户对应的 sessionId，以后每一次前端发起请求会携带上这个 cookie，后端从里面解析到 sessionId 后找到对应的 session 信息，就知道是谁再操作了。缺点是后端需要空间存储 session，用户多了，服务器多了都不方便，这种方式基本属于淘汰边缘。 （负载均衡有缺点，不好管理 session）
• jwt + token：前端登录后，后端会返回一个包括用户信息加密的 token 字符串（可能还有过期时间，手机端有设备唯一码等信息)，客户端自己保存了，将这个 token 设置到 header 里的 Authorization，之后每次请求都带上，服务器解码这个 token 之后就知道是谁在访问了。优点是不占存储空间，后端解码即可。

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（(RFC 7519).该 token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密。

介绍下如何实现 token 加密

Advanced-Frontend/Daily-Interview-Question#106

cookie 和 token 都存放在 header 里面，为什么只劫持前者？

token 不一定放在 header 里面
1、首先 token 不是防止 XSS 的，而是为了防止 CSRF 的；
2、CSRF 攻击的原因是浏览器会自动带上 cookie，而浏览器不会自动带上 token
Advanced-Frontend/Daily-Interview-Question#31
https://blog.csdn.net/liucongmei92/article/details/114291125

参考链接
https://segmentfault.com/a/1190000013258488
https://cloud.tencent.com/developer/article/1683290
https://www.cnblogs.com/JamesWang1993/p/8593494.html