OAuth2.0详解

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.更新令牌

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