cookie、session、token、jwt、oauth

jwt

看另一篇博客

oauth

OAuth（Open Authorization）是一个关于授权（authorization）的开放网络标准，允许用户授权第三方 应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他 们数据的所有内容。OAuth在全世界得到广泛应用，目前的版本是2.0版。

应用场景
原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、 请求后台数据。
前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证
第三方应用授权登录，比如QQ，微博，微信的授权登录。

总结

token分有状态和无状态两种

状态指的是 服务端是否要存储相关信息

• 有状态 服务端还是要存一些验证信息
• 真正的无状态 jwt

session和token区别

session要放到cookie中，以sessionid的形式
token可以随便放在哪里 header头自己字段或者authon字段 或者放到请求body中

session 客户端只放sessionid
token 可以本地放一些 服务器放一些 或者全部本地（jwt）或者基本服务器（token相当于sessionid）

更少的数据库连接：因其基于算法来实现身份认证，在使用 JWT 时查询数据的次数更少(更少的数据连接不等于不连接数据库)，可以获得更快的系统响应时间。构建更简单：如果你的应用程序本身是无状态的，那么选择 JWT 可以加快系统构建过程。
跨服务调用：你可以构建一个认证中心来处理用户身份认证和发放签名的工作，其他应用服务在后续的用户请求中不需要(理论上)在询问认证中心，可使用自有的公钥对用户签名进行验证。
冗余的数据开销：一个 JWT 签名的大小要远比一个 Session ID 长很多，如果你对有效载荷(payload)中的数据不做有效控制，其长度会成几何倍数增长，且在每一次请求时都需要负担额外的网络开销。

cookie和token区别

cookie是浏览器自带的 由浏览器管理 会存在跨域问题以及CSRF攻击问题，必须放到cookie头
token是程序员手动去管理的
cookie存的信息和个数有限制 不同浏览器不同

session的局限性

把Sessin存储在Web中间件中（比如Tomcat），这种做法正在淘汰，因为这种方案对负载均衡不友好，也不利于快速伸缩。

把Session存在Redis和前端的才是最佳方案，尤其在微服务架构大行其道的情况下。

但是如果体量大 那么session的存储就比较麻烦 因为redis可能多台 分布式问题