OAuth2.0 協議的理解

OAuth(Open Authorization)協議就是爲用戶資源的受權提供了一個安全、開放、簡易的標準。

OAuth在第三方應用與服務提供商之間設置了一個受權層，第三方應用經過受權層獲取令牌，再經過令牌獲取信息。

 

1、OAuth中的一些名詞

Client 第三方應用程序，又稱客戶端。

Resource Owner 資源全部者。

Http service 提供http服務的服務提供商。

Authorization server 認證服務器，服務提供商專門用來處理認證的服務器。

Resource server 資源服務器，服務提供商專門用來提供用戶資源的服務器。

 

2、OAuth協議流程

+--------+                                 +-------------+
|        |--- (1) Authorization Request -->|   Resource  |
|        |<-- (2) Authorization Grant   ---|   Owner     |
|        |                                 +-------------+
|        |                                 
|        |                                 +-------------+
| Client |--- (3) Authorization Grant   -->|Authorization|
|        |<-- (4) Access Token          ---|   Server    |
|        |                                 +-------------+
|        |                                 
|        |                                 +-------------+
|        |--- (5) Access Token          -->|   Resource  |
|        |<-- (6) Protected Resource    ---|   Server    |
+--------+                                 +-------------+

一、第三方應用請求用戶給予受權。

二、用戶贊成給予第三方應用受權。

三、第三方應用使用上一步獲取的受權，向認證服務器申請令牌。

四、認證服務器對第三方應用進行認證，準確無誤後，發放令牌。

五、第三方應用使用令牌，向資源服務器獲取資源。

六、資源服務器確認令牌無誤後，向第三方應用開放資源。

不難看出，第二步是最關鍵的，第三方應用獲取了受權，就能夠經過受權獲取令牌，進而經過令牌獲取資源。

 

3、OAuth的四種受權模式

一、受權碼模式

　　功能最完整、流程最嚴密的受權模式。

　　特色就是經過第三方應用的後臺服務器，與服務提供商的認證服務器進行互動。

　　流程以下：

　　(1)、用戶使用第三方應用，第三方應用將用戶跳轉到認證服務器。

　　(2)、用戶選擇是否給第三方應用受權。

　　(3)、若是用戶給予受權，則認證服務器將用戶跳轉至事先指定的重定向URI(redirect_uri)，同時在URL附加上一個受權碼(code)。

　　(4)、第三方應用獲取受權碼(code)，附加上重定向URI(redirect_uri)，向認證服務器申請令牌。這一步是在第三方應用服務器後臺完成的，用戶不可見。

　　(5)、認證服務器確認受權碼(code)和重定向URI(redirect_uri)無誤後，向第三方應用發送令牌(access_token)和更新令牌(refresh_token)。

 

二、簡化模式

　　不經過第三方應用的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"受權碼"這個步驟，所以得名。

　　全部步驟在瀏覽器中完成，令牌對訪問者是可見的，且第三方應用不須要認證。

　　流程以下：

　　(1)、用戶使用第三方應用，第三方應用將用戶跳轉到認證服務器。

　　(2)、用戶選擇是否給第三方應用受權。

　　(3)、若是用戶給予受權，認證服務器將用戶跳轉至事先指定的重定向URI(redirect_uri)，在URI的hash部分包含了訪問令牌。

　　(4)、瀏覽器向資源服務器發出請求，想要提取URI中的令牌(access_token)。

　　(5)、資源服務器返回帶有解析腳本的頁面，用於解析重定向URI中的令牌(access_token)。

　　(6)、瀏覽器使用解析腳本，獲取令牌。

　　(7)、瀏覽器將令牌發送給第三方應用。

 

三、密碼模式

　　用戶向第三方應用提供本身的用戶名和密碼。第三方應用使用這些信息，向服務商提供商索要受權。

　　在這種模式中，用戶必須把本身的密碼給第三方應用，可是第三方應用不得儲存密碼。

　　這一般用在用戶對第三方應用高度信任的狀況下，好比第三方應用是操做系統的一部分，或者由一個著名公司出品。

　　而認證服務器只有在其餘受權模式沒法執行的狀況下，才能考慮使用這種模式。

　　流程以下：

　　(1)、用戶將用戶名和密碼提供給第三方應用。

　　(2)、第三方應用將用戶名和密碼發送給認證服務器，申請令牌。

　　(3)、認證服務器確認無誤後，向第三方應用提供令牌。

 

四、客戶端模式

　　指第三方應用以本身的名義，而不是以用戶的名義，向服務提供商進行認證。

　　嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。

　　在這種模式中，用戶直接向第三方應用註冊，第三方應用以本身的名義要求服務提供商提供服務，其實不存在受權問題。

 　　流程以下：

　　(1)、第三方應用向認證服務器申請令牌。

　　(2)、認證服務器確認無誤後，向第三方應用提供令牌。

 

4、以接入QQ第三方登錄爲例

一、首先咱們須要到https://connect.qq.com/建立一個開發者帳號，審覈經過後，獲取到appid和appkey。

二、在網站上放置QQ登陸按鈕。

三、當用戶點擊QQ登陸按鈕，則會跳轉至QQ的受權地址。

https://graph.qq.com/oauth2.0/authorize?response_type=code&state=&client_id=&redirect_uri=

四、用戶給予受權後，頁面將跳轉至上一步redirect_uri設置的地址，並附加上受權碼(code)。

五、經過受權碼，向認證服務器申請令牌(access_token)。

https://graph.qq.com/oauth2.0/token?grant_type=authorization_code&client_id=&client_secret=&code=&redirect_uri=

六、經過令牌，咱們就能夠拿到用戶的openid。

https://graph.qq.com/oauth2.0/me?access_token=

七、經過appid，openid和令牌，咱們就能夠獲取用戶信息了。

https://graph.qq.com/user/get_user_info?access_token=&oauth_consumer_key=&openid=