1.使用场景

A系统存放着订单信息

B系统需要查询A系统中的订单信息，但是必须要A系统验证通过后，才能查询。

此时，我们有两种验证方式：

1)拥有A系统的账户/密码

  弊端是对A系统来说，直接提供账户/密码的方式非常不安全。

2)A系统给B系统颁发一个令牌，规定了令牌的使用范围和有效期，可以理解为一个通行证。

第二种方式，就是我们所说的OAuth授权。

2.OAuth原理

我们称待授权系统为“客户端”，授权系统为“服务器”

OAuth的原理是，“客户端”不能直接登录“服务器”，“客户端”登录时，“服务端”有一个“授权层”，会首先检验颁发给“客户端”的“令牌”是否有效，若有效，则允许登录。

3.OAuth验证流程

（A）客户端请求用户授权

（B）用户同意授权给客户端

（C）客户端使用上一步获得的授权，像服务器申请令牌

（D）服务器对客户端进行认证后，确认无误，同意发送令牌

（E）客户端使用令牌，向服务器请求资源

（F）服务器确认令牌无误，返回资源

上述步骤中，关键是用户如何给客户端授权。有了授权后，客户端就可以获得令牌，继而获得资源。

4.客户端授权的四种模式

授权码模式

简化模式

密码模式

客户端模式

5.授权码模式

（A）用户访问客户端，客户端将用户导向服务器，包含了“重定向URI”地址

（B）用户选择是否给予客户端授权

（C）若给予，服务器将用户导向“重定向URI”地址，同时附上一个授权码

（D）客户端收到授权码，附上“重定向URI”地址，向服务器申请令牌

（E）服务端核对授权码和重定向URI，确认无误，向客户端发送访问令牌和更新令牌

授权模式的特点是，需要通过客户端服务器，来和服务器端进行交互。

6.简化模式

简化模式不需要客户端服务器，直接通过浏览器向服务器申请令牌，跳过了“授权码”

所有步骤在浏览器中完成，不需要认证客户端。

（A）客户端将用户导向服务器

（B）用户决定是否给予客户端授权

（C）若授权，服务器将用户导向客户端指定的“重定向URI”，URI的hash部分包含了访问令牌。

（D）浏览器向服务器发出请求，不包括上一步收到的hash值

（E）服务器返回一个网页，其中包含的代码可以获取hash值中的令牌

（F）浏览器执行上一步获得的脚本，提取出令牌

（G）浏览器将令牌发给客户端

7.密码模式

用户向客户端提供自己的用户名和密码，客户端使用用户名/密码，向服务器索要授权

客户端不得储存密码，通常是一些大品牌信誉好的公司，才用这种模式。

（A）用户向客户端提供用户名/密码

（B）客户端讲用户名/密码发给服务器，请求令牌

（C）服务器确认无误，向客户端提供访问令牌

8.客户端模式

客户端以自己的名义，而不是用户的名义，向服务器进行认证。用户直接向客户端注册，客户端以自己的名义要求服务器提供服务，其实不存在授权问题。

（A）客户端向服务器进行身份认证，并要求一个访问令牌

（B）服务器确认无误，向客户端提供访问令牌

9.更新令牌

客户端的访问令牌过期后，需要使用更新令牌申请一个新的访问令牌

OAuth2.0详解