关于Oauth2 的详细介绍官网地址：https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth
1：什么是OAuth2
2：为什么要用OAuth2
工作流程图：
3：OAuth2 组件
①：Resource Owner: 资源拥有者。
②：Resource Server: 提供资源访问的资源服务器
③：Client: 访问服务器资源的客户端
④：Authorization Server: 认证服务器
4：OAuth Token
①：access_token
存在过期时间，可能是12个小时，由Authorization Server 颁发并决定它的过期时间。
②：refresh_token
一般比access_token的过期时间长点，用来重新获取access_token。
默认的Oauth Token 是UUID 形式存在的。当然我们也可以将 token 的结构以JWT的形式颁发给客户端。
4.1：JWT简单介绍
JWT 通常分为三部分，中间用 . 隔开，分别为 header、payload、signature。
①：header
头部包括令牌的类型（即JWT）及使⽤的哈希算法（如HMAC SHA256或RSA），例如:
{
"alg": "HS256",
"typ": "JWT"
}
②：payload
第⼆部分是负载，内容也是⼀个json对象，它是存放有效信息的地⽅，它可以存放jwt提供的现成
字段，⽐ 如：iss（签发者）,exp（过期时间戳）, sub（⾯向的⽤户）等，也可⾃定义字段。 此部
分不建议存放敏感信息，因为此部分可以解码还原原始内容。
{
"expire": "1234567890",
"username": "ZhangSan",
"role":["admin"]
}
③：Signature
第三部分是签名，此部分⽤于防⽌jwt内容被篡改。 这个部分使⽤base64url将前两部分进⾏编
码，编码后使⽤点（.）连接组成字符串，最后使⽤header中声明 签名算法进⾏签名。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
打开 jwt.io官网 便有展示的例子：
4.2：JWT 与 session 的区别
在很多情况下，我们会采用session共享的技术方案去解决集群条件下登录状态的问题。比如Spring-Session框架就很好解决了这个问题。
那么为什么还需要JWT呢？
区别一：是否需要存储在服务端？
session共享需要存放在redis或者其他分布式缓存中，以保证每个服务节点能共享session。
而JWT并不需要存储在服务端，客户端可以将token存放在Cookie或者LocalStorage中，并在发送请求的时候带上就行，服务端只是将JWT解密出来并校验而已。
区别二：对于跨系统的sso谁更出色？
个人认为是JWT更出色，因为A系统颁发的token，B系统只需要具备识别token的机制即可，不需要和A系统进行交互即可认证（前提是A、B系统的用户资料需同步）。
5：OAuth2 四种授权模式
5.1：Authrization Code Grant Type
A：用户发送请求到 Auth Server，请求需携带客户端凭证、redirect_uri、授权类型(code) 信息。
B：Auth Server校验客户端凭证是否通过，通过则调到登录页，不通过则返回错误。
C：用户在登录页输入用户名+密码，再请求到 Auth Server 。
D：Auth Server校验用户名+密码是否正确，不正确返回错误，正确调到redirect_uri 地址并在地址上拼接上code。
E：用户拿到 code 调用/oauth/token 接口带上code作为参数，以授权码模式（authorization_code）换取 token。
F：Auth Server 对code进行校验（code具备过期时间，且只能使用一次，无论换token是否成功或者失败），失败返回错误，成功则发放token。
G：拿到token之后用户便是一个Resource Owner，可以带上token 访问自己的资源。如访问属于自己的用户资料。
H：用户对token进行鉴权，通过之后返回正确的响应体，否则返回错误。
5.2：Password Grant Type
A：用户发送携带客户端凭证、用户名密码、授权类型（password） 信息的请求到Auth Server。
B：Auth Server 先校验客户端凭证是否正确，不正确返回错误。
C：再校验用户名密码是否合法，不合法返回错误。
D：B、C全部通过，Auth Server 发放token给客户端。
E：拿到token之后用户便是一个Resource Owner，可以带上token 访问自己的资源。如访问属于自己的用户资料。
F：用户对token进行鉴权，通过之后返回正确的响应体，否则返回错误。
5.3：Client Credentials Grant Type
A：用户发送携带客户端凭证、授权类型（client_credentials）的请求到Auth Server。
B：服务端进行校验之后，不通过则返回错误，通过则发放token（不返回refresh_token）。
5.4：Implicat Grant Type
A：用户发送请求到 Auth Server，请求需携带客户端凭证、redirect_uri、授权类型(token) 信息。
B：Auth Server 对客户端凭证进行校验，失败返回错误，成功重定向到授权页。
C：用户选择具体的scope，点击 Approval/Deny 按钮，并发送认证请求到 Auth Server。
D：用户若是点击了Deny 再发送请求，服务端返回错误信息，用户若是点了Approval 按钮，则返回可用的token（token未失效则是发放旧的token）。
授权码模式（authorization_code）和简易模式（implicat）中参数解析：