一. 概述
OAuth2.0的规范要求，就是客户端（即通常是各个应用程序）要访问资源所有者时，经过资源所有者同意后，由Oauth向这个客户端颁发令牌。为了满足互联网不同的场景 ，规定了四种获得令牌的流程，你可以根据需要选择其中一个最适自己的获取令牌的方案。这四种分别是：授权码，简化式（又称隐藏式），密码式，客户端凭证式。这四种模式最终都是为了拿 到access_token令牌。
不管是哪一种授权方式，第三方应用申请令牌前，必须到系统备案，说明自己的身份，然后获取到两处身份识别码：
客户端（client ID) 和客户端密钥（client secret)。
没有备案过的第三方应用，是不会拿到令牌的。
二、授权码方式（即有一个资源所有者确认授权的页面，即生成授权码code)
应用场景 ：
1.适用于把自己的应用让非自己公司开发的应用程序调用时采用授权码方式。
2.自己的登录要采用微信，钉钉，微博等第三方应用的认证方式进行登录时。
3. 我们要调用第三方应用（非自己公司开发的应用）的相关api，例如调用微信的一些api.
工作原理：
- 用户访问一个客户端（即客户端的页面）时，客户端将请求重新定向到认证服务器。
- 认证服务器向用户展示一个授权的确权页面，用户可以同意或者拒绝。
- 用户授权（即同意客户端去访问），认证服务器生成一个code，同时带上client_id给应用服务器（即用户中心微服务，有时候此功能也在认证服务器同时实现），并且client_id查询对应的client_secret（即密钥）。
- 应用服务器将code,client_id,client_secret三个参数给认证服务器生成access_token和refresh_token。
- 客户端携带access_token去请求资源服务器。
- 认证中心验证token，访问真正的资源页面(即资源服务器开放受限的资源给客户端）。
大多数情况下，认证服务器和资源服务器在同一台机器上，逻辑上分开两个概念。
这个模式的特点是，最安全且支持refresh token.
案例：微信登录就是据于OAuth2.0协议标准构建的授权登录系统。
前提条件：
1.开发者到微信开放平台注册开发账号，同时拥有一个已审核通过的移动应用，并获得相应的AppID和AppSecret。
2.申请微信登录且通过审核后，可开始接入流程。
获取access_token的流程：
三、密码方式
应用场景：适用于自己开发的认证服务器，即各个应用是我们自己开发的，所以之间高度信任。
工作流程：
- 用户输入登录账号和密码去访问客户端（即客户端的页面）。
-
客户端将
客户端（client ID) 和客户端密钥（client secret)（这两个备案时由认证服务器管理者提供开发者），以及登录账号和密码给认证服务器请求生成令牌。
- 认证服务器确认无误后，向客户端提供访问令牌。
- 客户端带上令牌向资源服务器请求访问资源。
- 资源服务器返回资源（即真正的资源页面）。
这种模式也支持refresh token，refresh token的初衷主要是为了用户体验（当acces_token过期后）不想用户重复输入账号密码来换取新token，因而设计了refresh token用于换取新token
四、简化式（又称隐藏式）：相对于授权码模式少了一个code，所以叫简化或者隐藏了这个code.
应用场景：不推荐用，一般用在只有前端（即浏览器）没有后端的应用程序中。
工作流程：
1.用户访问客户端（即客户端页面），输入账号和密码
2.认证服务器给用户一个认证页面，用户授权后直接生成token.
3.客户端带上token去访问资源服务器。
总结：
简化（或叫隐藏）是相对授权码方式来说的，少了一个code生成环节，回调的url直接携带了token。
这种模式不支持refresh token。所以安全性考虑，token的时效要设置短一些。
五、客户端凭证式（为什么叫客户端呢？其实就是和用户账号与密码无关）
应用场景 ：适用我们完全信任的自己研发的各个后端服务端之间（即后台api服务消费者)的访问，这个过程不需要用户参与。
工作流程：
- 客户端向认证服务器进行身份认证，并要求一个访问令牌；
- 认证服务器确认无误（只确认client_id和client_secret是否对）后，向客户端提供访问令牌；
- 客户端携带令牌向资源服务器请求访问资源；
- 资源服务器返回资源。
总结：
由于后端服务之间的授权，所以不支持refresh token，主要没有必要了。
大总结：
-
密码模式（resource owner password credentials(
支持refresh token
)：这个常用，一般用于自己产品做认证中心，即做单点登录。 -
授权码模式（authorization code）(
正宗方式
)(
支持refresh token
)：这个常用，调用第三方应用，或者把自己的应用给别人调用时，采用此认证模式。 -
简化模式（implicit）(
为web浏览器应用设计
)(
不支持refresh token
)：用的少。 -
客户端模式（client credentials）(
为后台api服务消费者设计
)(
不支持refresh token
)：用的少。