经常会在一些推文中看到一个概念OAuth2.0，这个出现频率还挺高的，这一篇博客就来简单介绍一下下这是个啥。Tips:只涉及一些概念。
OAuth2.0是个啥?
先说OAuth，OAuth是Open Authorization的简写。
OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。
简单来说，它是一个协议，而本文的主角则是在OAuth的基础上的一个延续版本—OAuth2.0协议。但不向前兼容(即完全废止了OAuth1.0)。
那么这个协议具体干了些什么呢?
有一句话形容它，“可以使一个系统经过授权后可以直接访问另外一个系统”。 咋一听，有点像之前博客介绍过的单点登录(SSO),但是它们两可是不一样。
使用场景
这里介绍一个学习时，老师举例的场景：
假设，A网站是一个打印照片的网站，B网站是一个存储照片的网站，二者原本毫无关联。
如果一个用户想使用A网站打印自己存储在B网站的照片，那么A网站就需要使用B网站的照片资源才行。
按照传统的思考模式，我们需要A网站具有登录B网站的用户名和密码才行，但是，现在有了OAuth2，只需要A网站获取到使用B网站照片资源的一个通行令牌即可！这个令牌无需具备操作B网站所有资源的权限，也无需永久有效，只要满足A网站打印照片需求即可。
这么听来，是不是有点像单点登录？NONONO！千万不要混淆概念！单点登录是用户一次登录，自己可以操作其他关联的服务资源。OAuth2则是用户给一个系统授权，可以直接操作其他系统资源的一种方式。
但SpringSecurity的OAuth2也是可以实现单点登录的！
总结一句：SpringSecurity的OAuth2可以做服务之间资源共享，也可以实现单点登录！
OAuth2.0中四种授权方式
这里还是上文举到的例子,放一张图：
授权码模式（authorization code）
-
流程
说明：【A服务客户端】需要用到【B服务资源服务】中的资源
第一步：【A服务客户端】将用户自动导航到【B服务认证服务】，这一步用户需要提供一个回调地址，以备【B服务认证服务】返回授权码使用。
第二步：用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】，这一步需要用户登录B服务，也就是说用户要事先具有B服务的使用权限。
第三步：【B服务认证服务】生成授权码，授权码将通过第一步提供的回调地址，返回给【A服务客户端】。
注意这个授权码并非通行【B服务资源服务】的通行凭证。
第四步：【A服务认证服务】携带上一步得到的授权码向【B服务认证服务】发送请求，获取通行凭证token。
第五步：【B服务认证服务】给【A服务认证服务】返回令牌token和更新令牌refresh token。
-
使用场景
授权码模式是OAuth2中最安全最完善的一种模式，应用场景最广泛，可以实现服务之间的调用，常见的微
信，QQ等第三方登录也可采用这种方式实现。
简化模式（implicit）
- 流程
说明：简化模式中没有【A服务认证服务】这一部分，全部有【A服务客户端】与B服务交互，整个过程不再有授权码，token直接暴露在浏览器。
第一步：【A服务客户端】将用户自动导航到【B服务认证服务】，这一步用户需要提供一个回调地址，以备【B服务认证服务】返回token使用，还会携带一个【A服务客户端】的状态标识state。
第二步：用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】，这一步需要用户登录B服务，也就是说用户要事先具有B服务的使用权限。
第三步：【B服务认证服务】生成通行令牌token，token将通过第一步提供的回调地址，返回给【A服务客户端】。
- 使用场景
适用于A服务没有服务器的情况。比如：纯手机小程序，JavaScript语言实现的网页插件等。
密码模式（resource owner password credentials）
-
流程
第一步：直接告诉【A服务客户端】自己的【B服务认证服务】的用户名和密码
第二步：【A服务客户端】携带【B服务认证服务】的用户名和密码向【B服务认证服务】发起请求获取
token。第三步：【B服务认证服务】给【A服务客户端】颁发token。
使用场景此种模式虽然简单，但是用户将B服务的用户名和密码暴露给了A服务，需要两个服务信任度非常高才能使用。
客户端模式（client credentials）
-
流程
说明：这种模式其实已经不太属于OAuth2的范畴了。A服务完全脱离用户，以自己的身份去向B服务索取token。换言之，用户无需具备B服务的使用权也可以。完全是A服务与B服务内部的交互，与用户无关了。
第一步：A服务向B服务索取token。
第二步：B服务返回token给A服务。
-
使用场景
A服务本身需要B服务资源，与用户无关。
OAuth2.0扮演的角色
介绍完了OAuth2.0的四种模式，但是OAuth2.0在其中扮演的是什么角色呢?
这里有一张图:
之前我们介绍的授权码模式中,负责颁发token就是OAuth2.0的服务端，而当A系统拿到授权码时，可以访问到B系统的资源称为OAuth2.0的资源端。
在这之前，A系统需要得到B系统的访问许可，怎么得到呢?
这里有两种方式。一个是在B系统的内存中保存A系统的访问许可，另外一个是在数据库中。想一想都知道，现在开发还是数据库中比较多。假设我们要做一个微信登录，那么微信应该会提供一个接口给我们，我们调用该接口后，就往微信的某张数据库表里保存了微信对我们的登录许可，之后就可以直接用微信登录了。而如果在内存中的话，每一次新增一个许可，就要去手动改对应代码，特别麻烦…
而这个数据库表其实Security已经帮我们规定好了，就像之前持久化token一样，规定好了表名和表的字段，只需要去官网执行对应的脚本即可。
今天关于OAuth2.0的一些概念先介绍到这里，感谢观看🙏