OAuth2.0基本原理及應用

 OAuth2.0基本原理及應用

一.OAuth是一個關於受權（authorization）的開放網絡標準，在全世界獲得普遍應用，目前的版本是2.0版。

在詳細講解OAuth 2.0以前，須要瞭解幾個專用名詞，理解它們對理解OAuth2.0的基本原理很重要。

（1） Third-party application：第三方應用程序，本文中又稱"客戶端"（client）。

（2）HTTPservice：HTTP服務提供商，本文中簡稱"服務提供商"。

（3）ResourceOwner：資源全部者，本文中又稱"用戶"（user），簡稱RO。

（4）UserAgent：用戶代理，本文中就是指瀏覽器,簡稱UA。

（5）Authorizationserver：認證服務器，即服務提供商專門用來處理認證的服務器，簡稱AS。

（6）Resourceserver：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，能夠是同一臺服務器，也能夠是不一樣的服務器，簡稱RS。

二．OAuth2.0實現方法

1.OAuth2.0在"客戶端"與"服務提供商"之間，設置了一個受權層（authorization layer）。"客戶端"不能直接登陸"服務提供商"，只能登陸受權層，以此將用戶與客戶端區分開來。"客戶端"登陸受權層所用的令牌（token），與用戶的密碼不一樣，用戶能夠在登陸的時候，指定受權層令牌的權限範圍和有效期。

"客戶端"登陸受權層之後，"服務提供商"根據令牌的權限範圍和有效期，向"客戶端"開放用戶儲存的資料。

三．OAuth2.0運行流程

   

（A）用戶打開客戶端之後，客戶端要求用戶給予受權。

（B）用戶贊成給予客戶端受權。

（C）客戶端使用上一步得到的受權，向認證服務器申請令牌。

（D）認證服務器對客戶端進行認證之後，確認無誤，贊成發放令牌。

（E）客戶端使用令牌，向資源服務器申請獲取資源。

（F）資源服務器確認令牌無誤，贊成向客戶端開放資源。

  上面六個步驟之中，B是關鍵，即用戶怎樣才能給客戶端受權，有了這個受權之後，客戶端就能夠獲取令牌，進而憑令牌獲取資源。

四．客戶端受權4中模型

  客戶端必須獲得用戶的受權（authorization grant），才能得到令牌（access token），OAuth 2.0定義了四種受權方式。

• 受權碼模式（authorization code）
• 簡化模式（implicit）
• 密碼模式（resource owner password credentials）
• 客戶端模式（client credentials）

1. 受權碼模式（authorization code）：

受權碼模式（authorization code）是功能最完整、流程最嚴密的受權模式。

具體步驟以下：

  （A）用戶訪問客戶端，後者將前者導向認證服務器。

（B）用戶選擇是否給予客戶端受權。

（C）假設用戶給予受權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個受權碼。

（D）客戶端收到受權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的後臺的服務器上完成的，對用戶不可見。

（E）認證服務器覈對了受權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。

下面是上面這些步驟所須要的參數。

A步驟中，客戶端申請認證的URI，包含如下參數：

response_type：表示受權類型，必選項，此處的值固定爲"code"

client_id：表示客戶端的ID，必選項

redirect_uri：表示重定向URI，可選項

scope：表示申請的權限範圍，可選項

state：表示客戶端的當前狀態，能夠指定任意值，認證服務器會原封不動地返回這個值

舉個例子:

C步驟中，服務器迴應客戶端的URI，包含如下參數：

code：表示受權碼，必選項。該碼的有效期應該很短，一般設爲10分鐘，客戶端只能使用該碼一次，不然會被受權服務器拒絕。該碼與客戶端ID和重定向URI，是一一對應關係。

state：若是客戶端的請求中包含這個參數，認證服務器的迴應也必須如出一轍包含這個參數。

下面是一個例子：

D步驟中，客戶端向認證服務器申請令牌的HTTP請求，包含如下參數：

grant_type：表示使用的受權模式，必選項，此處的值固定爲"authorization_code"。

code：表示上一步得到的受權碼，必選項。

redirect_uri：表示重定向URI，必選項，且必須與A步驟中的該參數值保持一致。

client_id：表示客戶端ID，必選項。

下面是一個例子。

E步驟中，認證服務器發送的HTTP回覆，包含如下參數：

access_token：表示訪問令牌，必選項。

token_type：表示令牌類型，該值大小寫不敏感，必選項，能夠是bearer類型或mac類型。

expires_in：表示過時時間，單位爲秒。若是省略該參數，必須其餘方式設置過時時間。

refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項。

scope：表示權限範圍，若是與客戶端申請的範圍一致，此項可省略。

下面是一個例子。

2. 簡化模式（implicit）

簡化模式（implicit grant type）不經過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"受權碼"這個步驟，所以得名。全部步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不須要認證。

它的具體步驟以下：

（A）客戶端將用戶導向認證服務器。

（B）用戶決定是否給於客戶端受權。

（C）假設用戶給予受權，認證服務器將用戶導向客戶端指定的"重定向URI"，並在URI的Hash部分包含了訪問令牌。

（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。

（E）資源服務器返回一個網頁，其中包含的代碼能夠獲取Hash值中的令牌。

（F）瀏覽器執行上一步得到的腳本，提取出令牌。

（G）瀏覽器將令牌發給客戶端。

3.密碼模式（resource owner password credentials）

密碼模式（Resource Owner Password CredentialsGrant）中，用戶向客戶端提供本身的用戶名和密碼。客戶端使用這些信息，向"服務商提供商"索要受權。

在這種模式中，用戶必須把本身的密碼給客戶端，可是客戶端不得儲存密碼。這一般用在用戶對客戶端高度信任的狀況下，好比客戶端是操做系統的一部分，或者由一個著名公司出品。而認證服務器只有在其餘受權模式沒法執行的狀況下，才能考慮使用這種模式

它的具體步驟以下：

（A）用戶向客戶端提供用戶名和密碼。

（B）客戶端將用戶名和密碼發給認證服務器，向後者請求令牌。

（C）認證服務器確認無誤後，向客戶端提供訪問令牌。

4.客戶端模式（client credentials）：

客戶端模式（Client Credentials Grant）指客戶端以本身的名義，而不是以用戶的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種 模式中，用戶直接向客戶端註冊，客戶端以本身的名義要求"服務提供商"提供服務，其實不存在受權問題。

它的步驟以下：

（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。

（B）認證服務器確認無誤後，向客戶端提供訪問令牌。

五．令牌更新

若是用戶訪問的時候，客戶端的"訪問令牌"已通過期，則須要使用"更新令牌"申請一個新的訪問令牌。

客戶端發出更新令牌的HTTP請求，包含如下參數：

granttype：表示使用的受權模式，此處的值固定爲"refreshtoken"，必選項。

refresh_token：表示早前收到的更新令牌，必選項。

scope：表示申請的受權範圍，不能夠超出上一次申請的範圍，若是省略該參數，則表示與上一次一致。

下面是一個例子。

六．OAuth2.0應用舉例

  現就將移動應用微信登陸具體流程講解以下：

1.移動應用微信登陸

在進行微信OAuth2.0受權登陸接入以前，在微信開放平臺註冊開發者賬號，並擁有一個已審覈經過的移動應用，並得到相應的AppID和AppSecret。

受權流程說明：

  1)第三方發起微信受權登陸請求，微信用戶容許受權第三方應用後，微信會拉起應用或重定向到第三方網站，而且帶上受權臨時票據code參數；

  2)經過code參數加上AppID和AppSecret等，經過API換取access_token；

 3)經過access_token進行接口調用，獲取用戶基本數據資源或幫助用戶實現基本操做；

獲取access_token時序圖

 

第一步：請求CODE

開發者須要配合使用微信開放平臺提供的SDK進行受權登陸請求接入，正確接入SDK後並擁有相關受權域（scope）權限後，開發者移動應用會在終端本地拉起微信應用進行受權登陸，微信用戶確認後微信將拉起開發者移動應用，並帶上受權臨時票據（code）

Android平臺應用受權登陸接入代碼示例：

參數說明

參數	是否必須	說明
appid	是	應用惟一標識，在微信開放平臺提交應用審覈經過後得到
scope	是	應用受權做用域，如獲取用戶我的信息則填寫snsapi_userinfo
state	否	用於保持請求和回調的狀態，受權請求後原樣帶回給第三方，該參數可用於防止csrf攻擊

拉起微信打開受權登陸頁返回值說明：

用戶點擊受權後，微信客戶端會被拉起，跳轉至受權界面，用戶在該界面點擊容許或取消，SDK經過SendAuth的Resp返回數據給調用方

返回值	說明
ErrCode	ERR_OK = 0(用戶贊成) ERR_AUTH_DENIED = -4（用戶拒絕受權） ERR_USER_CANCEL = -2（用戶取消）
code	用戶換取access_token的code，僅在ErrCode爲0時有效
state	第三方程序發送時用來標識其請求的惟一性的標誌，由第三方程序調用sendReq時傳入，由微信終端回傳，state字符串長度不能超過1K
lang	微信客戶端當前語言
country	微信用戶當前國家信息

第二步：經過code獲取access_token

獲取第一步的code後，請求如下連接獲取access_token

參數說明

參數	是否必須	說明
Appid	是	應用惟一標識，在微信開放平臺提交應用審覈經過後得到
Secret	是	應用密鑰AppSecret，在微信開放平臺提交應用審覈經過後得到
Code	是	填寫第一步獲取的code參數
grant_type	是	填authorization_code

正確返回參數說明：

特別的Unionid：當且僅當該移動應用已得到該用戶的userinfo受權時，纔會出現該字段；；

1.刷新access_token有效期

access_token是調用受權關係接口的調用憑證，因爲access_token有效期（目前爲2個小時）較短，當access_token超時後，可使用refresh_token進行刷新，access_token刷新結果有兩種；

 1）若access_token已超時，那麼進行refresh_token會獲取一個新的access_token，新的超時時間；

 2）若access_token未超時，那麼進行refresh_token不會改變access_token，但超時時間會刷新，至關於續期access_token；

refresh_token擁有較長的有效期（30天），當refresh_token失效的後，須要用戶從新受權

請求方法：

獲取第一步的code後，請求如下連接進行refresh_token：

參數說明：

參數	是否必須	說明
Appid	是	應用惟一標識
grant_type	是	填refresh_token
refresh_token	是	填寫經過access_token獲取到的refresh_token參數

正確返回的參數：

注意：

  1）Appsecret是應用接口使用密鑰，泄漏後將可能致使應用數據泄漏、應用的用戶數據泄漏等高風險後果；存儲在客戶端，極有可能被惡意竊取（如反編譯獲取Appsecret）；

2）access_token 爲用戶受權第三方應用發起接口調用的憑證（至關於用戶登陸態），存儲在客戶端，可能出現惡意獲取access_token 後致使的用戶數據泄漏、用戶微信相關接口功能被惡意發起等行爲；

3）refresh_token 爲用戶受權第三方應用的長效憑證，僅用於刷新access_token，但泄漏後至關於access_token 泄漏。

第三步：經過access_token調用接口

  1. access_token有效且未超時；

  2. 微信用戶已受權給第三方應用賬號相應接口做用域（scope）

對於接口做用域（scope），能調用的接口有如下：

受權做用域（scope）	接口	接口說明
snsapi_base	/sns/oauth2/access_token /sns/oauth2/refresh_token	經過code換取access_token、refresh_token和已受權scope 刷新或續期access_token使用
snsapi_userinfo	/sns/auth /sns/userinfo	檢查access_token有效性 獲取用戶我的信息

其中snsapi_base屬於基礎接口，若應用已擁有其它scope權限，則默認擁有snsapi_base的權限，使用snsapi_base可讓移動端網頁受權繞過跳轉受權登陸頁請求用戶受權的動做，直接跳轉第三方網頁帶上受權臨時票據（code），但會使得用戶已受權做用域（scope）僅爲 snsapi_base，從而致使沒法獲取到須要用戶受權才容許得到的數據和基礎功能。