OAuth 2.0 是一个行业的标准授权协议。OAuth 2.0 专注于简化客户端开发人员，同时为 Web 应用程序，桌面应用程序，手机等各种设备接入提供特定的授权流程。
传统登陆方式是在每个服务进行登陆认证， 每个服务保存自己的用户数据， 并独立实现登陆认证逻辑。
随着服务的不断扩展， 用户数据很难集中统一，开发成本不断增加， 用户交互也极为不便 。
单点登陆是通过统一认证授权服务， 完成所有服务节点的登陆授权工作。
只需一台认证服务器，统一用户数据库， 完成用户认证授权， 控制资源访问， 支持其他服务或第三方应用接入， 扩展性强， 开发和运维成本降低。
Resource Owner 与 Client 之间 ， 资源所有者向Client发起认证请求， Client再返回认证授权信息。
Client 收到 Resource Owner 的认证请求后， 会去Authorization Server 申请访问令牌， Authorization Server会让Client 进行认证， 通过之后会返回Access Token。
Client 拿到 Authorization Server 的 Acceess Token , 访问Resource Server，Resource Server 验证之后， 返回被保护的资源信息。
Resource Server 可以通过JWT在本地进行验证， 也可以访问 Authorization Server， 对Client 的请求的合法性进行验证。
OAuth2 分为四种授权类型， 分别为：
资源拥有者（用户）通过代理（WEB浏览器）访问客户端程序，发起授权码模式认证。
客户端（Client，比如CSDN论坛）向认证服务器（Auth Server，QQ账号认证服务）发起请求， 此时客户端携带了客户端标识（client_id， 标识来源是CSDN）和重定向地址（redirect_uri， 一般是CSDN的地址）。
用户确认授权，客户端（Client）接收到code。
在重定向的过程中，客户端拿到 code 与 client_id、client_secret 去授权服务器请求令牌，整个过程，用户代理是不会拿到令牌 token 的。
客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了， 比如获取QQ基本资料， 头像等信息。
授权请求：
response_type=code // 必选项
&client_id={客户端的ID} // 必选项
&redirect_uri={重定向URI} // 可选项
&scope={申请的权限范围} // 可选项
&state={任意值} // 可选项
授权响应参数：
code={授权码} // 必填
&state={任意文字} // 如果授权请求中包含 state的话那就是必填
令牌请求：
grant_type=authorization_code // 必填
&code={授权码} // 必填 必须是认证服务器响应给的授权码
&redirect_uri={重定向URI} // 如果授权请求中包含 redirect_uri 那就是必填
&code_verifier={验证码} // 如果授权请求中包含 code_challenge 那就是必填
令牌响应：
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":{过期时间}, // 任意
"refresh_token":"{刷新令牌}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
授权请求：
response_type=code // 必选项
&client_id={客户端的ID} // 必选项
&redirect_uri={重定向URI} // 可选项
&scope={申请的权限范围} // 可选项
&state={任意值} // 可选项
授权响应参数：
&token_type={令牌类型} // 必填
&expires_in={过期时间} // 任意
&state={任意文字} // 如果授权请求中包含 state 那就是必填
&scope={授权范围} // 如果请求和响应的授权范围不一致就必填
为什么要有授权码和简化模式？看完这两种模式， 可能会有些疑问， 为什么要这么麻烦， 直接一次请求返回TOKEN不就可以吗？
可以看出， 两者主要差别， 是少了code验证环节， 直接返回token了， code验证是客户端与认证服务器在后台进行请求获取， 代理是获取不到TOKEN的， 如果缺少这个环节， 直接返回TOKEN， 相当于直接暴露给所有参与者， 存在安全隐患， 所以简化模式，一般用于信赖度较高的环境中使用。
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
令牌请求：
grant_type=password // 必填
&username={用户ID} // 必填
&password={密码} // 必填
&scope={授权范围} // 任意
令牌响应：
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":"{过期时间}", // 任意
"refresh_token":"{刷新令牌}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
此模式简化相关步骤， 直接通过用户和密码等隐私信息进行请求认证， 认证服务器直接返回token， 这需要整个环境具有较高的安全性。
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
这种模式一般在内部服务之间应用， 授权一次， 长期可用， 不用刷新token。
令牌请求：
grant_type=client_credentials // 必填
&scope={授权范围} // 任意
令牌响应：
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":"{过期时间}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填