Oauth2.0认证模式

背景

首先token认证方式的出现是伴随着系统架构的发展而来的。

最初的单机应用使用sessionId+cookie完全可以满足问题。

随着系统业务访问量加大，为满足服务高可用需求，系统引入了分布式架构，但是session只能存在单机节点上，为了解决这一问题，首先使用过session粘贴技术（通过hash等手段让请求始终访问之前生成sessionId的节点），这个方案的问题是万一存sessionId的节点挂了，整个系统都不能登陆了，也违背了高可用的设计思路；后来使用session复制的方案，即每台节点都copy一份sessionId，这引出2个问题，第一个就是分布式一致性的问题，节点同一时间重复创建了怎么办？另一个就是更头疼的系统扩展问题，随着系统越来越庞大，节点增多，session复制消耗的性能也越来越大，整个系统因为session出现了可遇见的性能瓶颈；再后来出现了session集中存储到一个地方，这样解放了服务器，但是session存储的高可用问题又来了，简直就是套娃式困局。

既然有状态服务出现瓶颈，大佬们开始提出无状态服务，就是使用token验证方式替代较重的session，token就是一个字符串，只要服务根据约定好的算法解析出的结果跟预期一致就可以通过验证，也不需要保存在内存中，无状态服务的好处是系统扩展轻松，新追加的服务轻装上阵，完全没有顾虑。Oauth就是一种规范，用来保证token机制的可行，目前在web端和移动端都是主流登陆验证方案，Oauth2.0于2010年正式提出，一直沿用到现在，可见其稳定。

随着互联网行业迅猛发展，各种app，各种网站层出不穷，传统登陆方式就要求用户在每个想登陆的站点都要注册自己的账号信息和密码，这也留下了一定隐患，有的小站点可能技术不那么强，这就有可能导致用户信息泄漏，Oauth正好可以解决这种对一些站点即想用又不信任问题。从使用体验的角度，单点登陆的方式也可以简化用户对账号密码的管理。

Oauth2认证模式的4种类型

1. 授权码模式

这种模式最常用，也是最安全的模式，相关的角色有3个：
客户端（web站点/app，从认证服务的视角，不管你是web页面还是后台服务，都属于客户端范畴）、资源服务（存放个人信息的服务，比如微信存放你个人信息的服务）、认证服务（某可信的账户平台如微信平台）

使用之前需要在认证服务注册下自己的app信息（主要包括app名称、app站点、认证callback地址等），认证平台会给客户端创建一个clientId（客户端id）和client_secret（客户端秘钥）。这是为了解决认证平台不信任客户端的问题。

使用的时候用户首先会点击客户端登陆页上的一个链接，打开认证服务上的一个登陆确认页面，用户认证的时候会上传以下请求参数：

1. clientId
2. redirect_uri 登陆确认后页面重定向的地址
3. response_type 这个参数的值必须是code，代表授权码模式
4. state (可选) 这个参数是客户端自己生成的随机数/随机串，认证服务重定向的时候会带上这个state，用以表明自己的身份，这个参数主要用来防止csrf攻击。
5. scope（可选）请求资源的范围，多个用空格隔开

认证成功后，认证服务会重定向到redirect_uri,
同时认证服务还会按照之前注册好的callback地址，向客户端发一个get请求，参数：

1. code 就是授权码
2. state (可选) 这个是之前客户端生成的随机数，作用还是防csrf攻击

这样客户端拿到了code，会再向认证平台的授权服务器发起请求，参数：

1. code
2. clientId
3. client_secret

授权服务验证code没问题后，会给客户端返回token。

客户端拿着token就可以去资源服务器请求用户信息了（头像、姓名等）。

2. 隐藏式(implicit)

这种模式大致流程是：

1. 用户在登录页上点击链接认证
2. 认证成功后认证服务器直接返回token

这个模式不经过code验证的过程，这种token可以直接在callback的uri上看到，并且客户端后台也不会验证token，这种模式安全性显然没有授权码模式好，应用也不多。

3. 密码模式

流程：
用户直接在客户端上输入账号密码，然后由客户端向认证服务请求要token。

要使用这种模式就表明用户完全信任客户端了，如果信任客户端，直接在客户端上注册账号不就好了，何必把其他平台的账号告诉客户端，万一客户端保存了这个账号密码呢？

4. 客户端模式

流程：
用客户端自己的名义向认证服务获取token，跟用户没什么关系。这也不会是登陆会考虑的场景吧...

http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
https://www.bilibili.com/video/BV1zt41127hX?spm_id_from=333.999.0.0