文章目录
1、OAuth2.0协议
- OAuth即开放授权，2.0即废止了复杂的OAuth1.0
- 允许用户授权第三方应用访问他们存储在另外已有账户的系统上的信息，且不需要将用户名和密码提供给第三方应用
比如：用户A微信扫码登录网站B，即用户A授权网站B去微信服务器拿自己的部分信息，以免去在网站B重复输入信息注册的麻烦，当然，你的微信登录密码，网站B并不知道。OAuth2.0则是定义了完成这个过程的一个标准流程。
2、角色
- 客户端：没用户信息资源，需要申请资源的那个第三方系统
- 资源拥有者：用户自己
- 认证授权服务器：对资源拥有者身份做认证，认证通过后给客户端发授权码
- 资源服务器：存用户信息的服务器，客户端携带拿到的token请求类似getUserInfo的接口，获取用户信息
3、名词
clinet_id，即客户端ID
和客户端密钥client_secret搭配使用，用来确认客户端身份，因为不是随便一个客户端系统都能请求认证服务器。客户端系统A没和我对接，也就没有客户端ID和密钥，它的请求过来直接在网关就拦截了
授权码
用户的委派书，代表的是用户的意愿，比如用户愿意把微信昵称、头像信息给网站A，微信服务器你可以发给网站A了
access token，即访问令牌
用户同意授权后，客户端系统拿到授权码，并携带授权码请求认证授权服务器，告诉它，用户同意我从你这儿拿信息。认证授权服务器校验无误后发放token给客户端系统，即拿授权码换取token。access token解析后代表时间范围和权限范围，即在多长的时间范围内允许客户端系统访问哪些资源。
refresh token，即刷新令牌
access token有效时间太长，万一泄漏，隐患很大，有效时间太短，就又需要用户频繁授权，用户体验很差。由此，引入refresh token。上面的授权码换token时，除了返回access token，还有一个refresh token，同样与客户端系统、用户关联在一起。
刷新令牌时：
- 检测请求头里的app_id和app_secret是否在以对接的客户端系统之列
- 检测refresh_token的合法性
- 检测refresh_token的归属，是否是当前app_id的
1）当access_token未过期，且refresh_token也未过期，就用refresh_token刷新，可选：
- access_toekn不变，但过期时间更改，相当于给access_token续期了
- 新的access_toekn
- access_toekn不变，过期时间也不变（Spring Security）
2）当access_token过期，refresh_token未过期，则返回新的access_token，且refresh_token自身值以及过期时间不变。
3）当refresh_token也过期了，就需要用户重新授权。（起始状态）
关于第三方客户端系统何时用refresh_token来刷新令牌，可以写定时任务（授权码换token时，access_token的过期时间也返回过来了），也可以等出现access_token过期的返回结果时，再做刷新处理。
redirect_uri，即回调地址
发放授权码给客户端，是用302重定向到客户端请求里的redirect_uri的方式实现的。如果redirect_uri被篡改成一个恶意网站，则用户信息泄漏，如果redirect_uri被篡改成认证服务器，则消耗认证服务器性能。基于此问题，OAuth2协议规定：客户端注册自己的系统时，要配置回调地址（可一个、可多个），客户端系统请求上来时，检查redirect_uri是否在注册的redirect_uri集合之内，是，则发放授权码。且获取授权码和授权码换token传入的回调地址要一致。
scope，即授权范围
描述了一组权限信息，比如获取基本资料（头像、昵称）。这些授权范围信息同时也要展示给资源所有者。
4、授权模式
OAuth2.0的四种授权模式：
- 授权码模式
- 密码模式
- 简化模式
- 客户端模式
5、基本流程
以在网站A进行微信扫码登录为例（授权码模式）：
此时，系统A为对接的系统，即客户端，微信为资源服务器一方，时序图：
