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(用戶同意) |
| 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，從而導致無法獲取到需要用戶授權才允許獲得的數據和基礎功能。