oauth授权与五种模式

为何要使用OAuth协议？

举例子：第三方服务方提供服务，某些服务需要用户的同意才能够做到，好比客厅要装修，需要得到主人的同意，拿到钥匙，才能装修，提供服务。
传统做法：
把所有钥匙（账号密码）给工人。但这样，工人可能用这个钥匙开卧室的门。甚至打一个新的钥匙。
缺点：（不安全）
1）服务提供方只是提供一个服务，为了保证服务能提供，就会保存账号密码以供下次提供，这显然不安全。
2）服务提供方有了账号密码，就拥有了用户所有的权利，用户没办法限制服务提供方获得权限的范围和有效期。
3）用户只有修改密码，才能收回赋给服务方的权力。这样做，会使得其他所有获得用户授权的第三方全部失效。
4）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

客户端获取授权的五种模式：

1）授权码模式
授权码模式是功能最全、最安全的，其授权过程(如获取微信用户信息)：
a)用户登陆第三方应用，第三方应用需要获取该用户微信的个人资料
b)第三方把用户链接到微信的授权页面，用户点击授权,此时微信可以确切地知道用户是同意授权了，而不是由第三方应用伪造的同意动作
c)用户在微信的授权页面点击授权后，微信转跳回第三方应用页面并返回授权码，这个转跳回的页面是事先微信和第三方应用商量好的
d)第三方应用拿到授权码后(并不是token)，可以去微信请求token，微信检查授权码是否正确，返回token
e)第三方应用拿到token后去微信请求用户个人资料，微信根据该token可以读出授权范围，并进行相应的授权后返回个人资料

2）简化模式
有些纯前端应用，必须将令牌储存在前端。那么可以使用简化模式（隐藏式）来申请授权，颁发令牌。
a）浏览器向授权服务器申请授权，并设置response_type=token，表示直接返回令牌
b）授权服务器通过校验后跳转到重定向地址并返回token
c）浏览器通过token去申请资源

3）密码模式
密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
a）用户向客户端提供用户名和密码。
b）客户端将用户名和密码发给认证服务器，向后者请求令牌。
c）认证服务器确认无误后，向客户端提供访问令牌。

4）客户端模式
a）客户端向认证服务器进行身份认证，并要求一个访问令牌。
b）认证服务器确认无误后，向客户端提供访问令牌。
c）客户端携带令牌向资源服务器请求访问资源。
d）资源服务器返回资源。

5）扩展模式
SpringBoot OAuth2框架本身已实现集成授权码、客户端、密码、刷新令牌等模式、现实使用中常常不能满足自身用户体系的认证，这样我们可以通过扩展授权模式的方式来实现。