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

客戶端的訪問令牌過時後，須要使用更新令牌申請一個新的訪問令牌