OAuth：每次受權暗中保護你的那個「MAN」

摘要：OAuth是一種受權協議，容許用戶在不將帳號口令泄露給第三方應用的前提下，使第三方應用能夠得到用戶在某個web服務上存放資源的訪問權限。

背景

在傳統模式下，用戶的客戶端在訪問某個web服務提供的具備必定訪問限制的資源時，須要提供用於進行身份認證的憑證（credential），例如密碼，accesskey等。若是存在第三方的應用須要該web服務上用戶的資源，用戶必須將本身的憑證共享給第三方應用，這種實踐帶來了一些問題：

1. 第三方應用須要存放用戶的憑證，且必須拿到明文（例如使用用戶名和密碼遠程調用web服務的API），若是第三方應用被攻擊，用戶的憑證可能被泄露。
2. 沒法限制第三方應用的權限。第三方應用拿到用戶憑證實文後，等於拿到了用戶的全部權限，且用戶沒法對第三方應用在什麼時間訪問哪些資源進行限制，可能被越權。
3. 用戶沒法回收對某個第三方應用的受權，除非更改密碼。更改密碼可能致使依賴該密碼的其餘第三方應用沒法訪問。
4. 用戶資源的安全性取決於安全性最弱的第三方應用（木桶理論），任何一個第三方應用被攻擊，均可能致使用戶的身份憑證泄露，以及存放在web服務上的資源被攻擊。

基本原理

OAuth是一種受權協議，容許用戶在不將帳號口令泄露給第三方應用的前提下，使第三方應用能夠得到用戶在某個web服務上存放資源的訪問權限。

例以下圖，經過華爲帳號登陸騰訊新聞應用時，並不須要將帳號口令提供給騰訊新聞應用，用戶只要擁有華爲帳號，只須要輕輕點擊一下受權就能夠無縫訪問，在保證安全和隱私的同時帶來體驗上質的飛躍，體驗提高的持續追求使得OAuth協議在互聯網獲得了很是普遍的應用。

OAuth經過引入authorization server的概念，並對受權訪問過程當中的幾個參與方進行從新定義和角色解耦。

上面是一個很是很是抽象的流程圖，僅僅爲了釐清OAuth交互過程當中存在哪些角色及承擔的職責，實際上具體應用過程當中的差別很是大。從上圖大概能夠看出，OAuth協議交互過程當中存在四種角色：

• resource owner

須要訪問資源的主體，能夠是人，也能夠是物，指代人的時候就是咱們一般說的end-user。

• resource server

存放受保護資源的web服務，接收資源的訪問請求並響應，resource server對請求進行鑑權。例如用戶存放照片的華爲終端雲服務。

• client

用來代理resource owner請求資源的應用程序，client訪問資源須要獲得resource owner的受權。例如照片美圖APP，須要拉取用戶存放在雲服務上的照片。

• authorization server

對resource owner進行身份認證和鑑權，並頒發訪問憑證。例如華爲帳號認證服務。

其餘說明

1. OAuth協議當前已經發展到0版本。1.0版本已經廢棄，且OAuth2.0並不能後向兼容1.0。
2. OAuth協議經常使用於web訪問，基於HTTP協議。實際上，OAuth只是定義了一種流程，以及該流程中各方的角色定義和功能職責，並不限於HTTP這一種傳輸通道。
3. 上面的流程圖中並無介紹resource server和authorization server之間的交互，它們可能承載在同一個web服務中，也可能由不一樣的獨立web服務承載。當resource server和authorization server各自獨立時，正是由於OAuth協議沒有定義其交互過程，致使OAuth協議在產品標準化和工程化中出現困難，後面會慢慢介紹。

OAuth：受權流程

接下來咱們探討一下，獲取受權和獲取token的幾種模式，應用場景，交互過程以及API的定義。

分類

準備工做

在開始OAuth2.0的受權流程前，應用的開發者須要將應用的信息註冊到authorization server，例如華爲帳號服務、百度開發者中心這些知名的開放平臺，註冊成功後獲得最重要的兩個參數：client_id和client_secret，這兩個參數在後面介紹的幾乎每種受權流程都會頻繁使用。

以下圖華爲終端開發者聯盟管理中心註冊界面：

開發者進行應用註冊時，通常須要提交應用類型。應用類型常見的幾大類：

對於web application，開發者還須要提交redirect URI，即web application接收grant code的地址，authorization server在認證完成後重定向到此地址。

受權碼流程

受權碼流程是oauth2.0最多見的交互流程，甚至不少開放平臺僅支持這一種流程。受權碼流程示意見下圖：

該流程主要適用於web應用，基於瀏覽器的重定向能力實現整個交互過程。

錯誤返回

當resource-owner拒絕client的訪問請求，或者受權請求錯誤，authorization server將錯誤信息經過redirect_uri返回給client應用，除非redirect_uri自己就不正確。

參數

說明，全部參數需通過「application/x-www-form-urlencoded」編碼。

隱式受權（Implicit Grant）

如上面介紹，隱式受權適用於代碼運行在客戶端上的應用，例如網頁應用，利用瀏覽器的重定向能力獲得resource-owner的受權。不一樣於受權碼流程，隱式受權流程的受權請求能夠直接獲得access token，沒有authorization code的中間過程。隱式受權過程發生在resource owner的設備上，必須有resource owner在場，且client代碼不能包含client的憑證（client_secret），另外access_token返回給client時，存在暴露到同一個設備（user-agent）上其餘應用的風險。

身份信息透傳受權（Resource Owner Password Credentials Grant）

若是resource owner很是信任這個應用，能夠將身份憑證（口令，密鑰等）經過應用傳遞到authorization server。通常不推薦這種方式，應用能夠截留用戶的身份憑證實文，風險較高，RFC協議也僅建議用於存量的應用遷移到OAuth協議。我的認爲，若是client自己就是authorization server，其身份驗證過程這樣作也是可行的，至關於authorization server的內部實現。

客戶端憑證直接受權（Client Credentials Grant）

應用拿着client_id和client_secret直接從authorization server獲取access token，這種流程僅用於訪問應用自己的與resource owner無關的數據，不須要resource owner受權的場景，可使用這種受權，通常都是機機接口調用。

擴展應用

不一樣廠商的開放平臺能夠擴展受權流程，以知足不能場景的需求，例如手機、平板等端側設備應用，或者電視、遊戲手柄等娛樂設備應用。

移動端和PC桌面的應用受權

對於運行在手機、平臺和PC上的應用程序，也能夠經過OAuth協議獲得用戶的受權來安全的訪問用戶的數據。這種場景的受權流程和web server應用很是相似，也是authorization grant模式，主要區別是此類應用須要提供本地web server或者支持應用間跳轉，並提供系統內置的「browser」（例如android的intent）實現與authorization server之間的交互。

這種受權方式的交互過程和接口和上文介紹得authorization grant模式同樣，惟獨受權請求的redirect_uri參數有差別：

電視或輸入受限設備的應用受權

當咱們在使用智能電視、遊戲手柄或者帶液晶屏的打印機須要訪問用戶的數據，例如放在網盤上的照片、文檔等，須要獲得用戶的受權，而這類設備的輸入能力有限，沒有瀏覽器進行重定向，也不方便輸入帳號口令等認證憑證。

此類場景的應用受權大體步驟以下：

Step1: 獲取device_code

-

Java 代碼

1
POST /device/code
2
Content-Type: application/x-www-form-urlencoded
3
4
client_id=client_id&response_type=device_code&scope=email%20profile 

Step2: 處理authorization響應

-

Java 代碼

{
    "device_code": "4/4-GMMhhdfkdkfgdgegkfkfkeegjgjgj",
    "user_code": "GQVQ-JKEC",
    "verification_url": "https://www.google.com/device",
"qrcode_url": "http://www.google.com/device/qrcode\ddggheghehhhdddddddddddddddhgerhh",   //二維碼
    "expires_in": 1800    // code有效期
    "interval": 5   // poll的間隔

Step3: 顯示user_code

能夠屏幕顯示verification_url和user_code，甚至若是支持的話能夠顯示二維碼。

Step4：poll用戶受權結果

APP根據第2步受權響應的interval間隔，向authorization server 拉取用戶的受權結果。

-

Javascript 代碼

POST /token
Content-Type: application/x-www-form-urlencoded
 
client_id={client_id}&
client_secret={client_secret}&
code={device_code}&
grant_type=device_code

Step5: 用戶打開瀏覽器輸入verification_url和user_code，或者經過手機掃碼完成登陸和受權。

Step6: 處理poll 響應

Javascript 代碼

{
    "access_token": "1/ffffdgdg",  
    "expires_in": 3920,
    "scope": "openid profile email",
    "token_type": "Bearer",
    "refresh_token": "dgegegegedgegeg"

}

OAuth：API定義和擴展

在上一篇中介紹了不一樣場景下的應用得到租戶受權的交互流程。本文主要介紹OAuth2.0協議的受權和token API定義及常見的擴展方案。OAuth2.0的全部參數都經過"urlencoded"編碼，在請求頭部須要增長「application/x-www-form-urlencoded」。

1. code受權請求API

適用於authorization code grant模式，應用經過瀏覽器將受權請求重定向給authorization server，除了經過重定向外，我認爲也能夠經過FORM表單提交。

1.1 參數

1.2 示例

GET /oauth2/authorize?response_type=code&

client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

1.3 擴展

看了Google的OAuth2.0接口定義，選取幾個實踐中比較有意義的擴展參數：

1.4 響應

authorization server完成用戶身份認證並獲得用戶受權後，將code做爲參數重定向給redirect_uri。

2. 隱式受權請求API

適用於implicit grant模式，瀏覽器JS直接向authorization server發送受權請求。

2.1 參數

2.2 示例

   GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

2.3 響應

認證服務器在完成用戶身份認證並獲得用戶的受權後，將回跳到redirect_uri，並攜帶access_token參數。

API定義和擴展

OAuth2.0的全部參數都經過"urlencoded"編碼，在請求頭部須要增長「application/x-www-form-urlencoded」。

1. code受權請求API

適用於authorization code grant模式，應用經過瀏覽器將受權請求重定向給authorization server，除了經過重定向外，我認爲也能夠經過FORM表單提交。

1.1 參數

1.2 示例

GET /oauth2/authorize?response_type=code&

client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

 

1.3 擴展

看了Google的OAuth2.0接口定義，選取幾個實踐中比較有意義的擴展參數：

1.4 響應

authorization server完成用戶身份認證並獲得用戶受權後，將code做爲參數重定向給redirect_uri。

2. 隱式受權請求API

適用於implicit grant模式，瀏覽器JS直接向authorization server發送受權請求。

2.1 參數

2.2 示例

  GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

2.3 響應

認證服務器在完成用戶身份認證並獲得用戶的受權後，將回跳到redirect_uri，並攜帶access_token參數。

本文分享自華爲雲社區《【系列集合篇】淺談OAuth二三事》，原文做者：APTX-486977。

 

點擊關注，第一時間瞭解華爲雲新鮮技術~