什么是Oauth2.0，Oauth2.0的四种授权模式

Oauth2.0本身：

OAuth2.0协议流程描述了四种角色之间的交互过程，如下图所示。

上面的序列图一共分为以下6个步骤：

（1）第三方应用请求资源所有者授权。

（2）资源所有者同意给第三方应用授权。

（3）第三方应用使用步骤2中获得的授权，向授权服务器申请令牌。

（4）授权服务器对第三方应用进行认证并确认无误后，同意发放令牌。

（5）第三方应用使用步骤4中发放的令牌向资源服务器申请获取资源。

（6）资源服务器确认令牌无误后，向第三方应用开放资源访问。

简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

令牌与密码

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。

（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。

（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。

注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。 这也是为什么令牌的有效期，一般都设置得很短的原因。

OAuth 2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权类型（authorization grant），即四种颁发令牌的方式，适用于不同的互联网场景。

1. 隐式授权模式（Implicit Grant）

第一步：用户访问页面时，重定向到认证服务器。 第二步：认证服务器给用户一个认证页面，等待用户授权。 第三步：用户授权，认证服务器想应用页面返回Token 第四步：验证Token，访问真正的资源页面

2. 授权码授权模式（Authorization code Grant）

第一步：用户访问页面 第二步：访问的页面将请求重定向到认证服务器 第三步：认证服务器向用户展示授权页面，等待用户授权 第四步：用户授权，认证服务器生成一个code和带上client_id发送给应用服务器 然后，应用服务器拿到code，并用client_id去后台查询对应的client_secret 第五步：将code、client_id、client_secret传给认证服务器换取access_token和 refresh_token 第六步：将access_token和refresh_token传给应用服务器 第七步：验证token，访问真正的资源页面

3. 密码模式（Resource Owner Password Credentials Grant）

缺点：局限性，认证服务器和应用方必须有超高的信赖。(比如亲兄弟？)

应用场景：自家公司搭建的认证服务器

4. 客户端凭证模式（Client Credentials Grant）

第一步：用户访问应用客户端 第二步：通过客户端定义的验证方法，拿到token，无需授权 第三步：访问资源服务器A 第四步：拿到一次token就可以畅通无阻的访问其他的资源页面。

这是一种最简单的模式，只要client请求，我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。

因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。