【系列集合篇】淺談OAuth二三事

【OAuth系列一】OAuth協議簡介

背景

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

第三方應用需要存放用戶的憑證，且必須拿到明文（例如使用用戶名和密碼遠程調用web服務的API），如果第三方應用被攻擊，用戶的憑證可能被泄露。

無法限制第三方應用的權限。第三方應用拿到用戶憑證明文后，等于拿到了用戶的所有權限，且用戶無法對第三方應用在什么時間訪問哪些資源進行限制，可能被越權。

用戶無法回收對某個第三方應用的授權，除非更改密碼。更改密碼可能導致依賴該密碼的其他第三方應用無法訪問。

用戶資源的安全性取決于安全性最弱的第三方應用（木桶理論），任何一個第三方應用被攻擊，都可能導致用戶的身份憑證泄露，以及存放在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進行身份認證和鑒權，并頒發訪問憑證。例如華為賬號認證服務。

其他說明

OAuth協議當前已經發展到0版本。1.0版本已經廢棄，且OAuth2.0并不能后向兼容1.0。

OAuth協議常用于web訪問，基于HTTP協議。實際上，OAuth只是定義了一種流程，以及該流程中各方的角色定義和功能職責，并不限于HTTP這一種傳輸通道。

上面的流程圖中并沒有介紹resource server和authorization server之間的交互，它們可能承載在同一個web服務中，也可能由不同的獨立web服務承載。當resource server和authorization server各自獨立時，正是因為OAuth協議沒有定義其交互過程，導致OAuth協議在產品標準化和工程化中出現困難，后面會慢慢介紹。

【OAuth系列二】授權流程

在上一篇中介紹了協議的基本流程：獲取授權->獲取token->訪問資源。本文主要探討獲取授權和獲取token的幾種模式，應用場景，交互過程以及API的定義。

分類

Grant Type

應用場景

Authorization Code Grant

適用于具有web server的應用，web server能夠安全的保存應用的憑證，并通過user-agent的重定向能力完成授權過程。

Implicit Grant

適用于client-side的應用，此類應用的代碼暴露運行在不安全的環境，不應該保存應用的憑證。例如運行在瀏覽器里的JavaScript應用，常見的SPA（單頁面應用 ）。此類應用也是通過user-agent的重定向能力完成授權過程。

Resource Owner Password Credentials Grant

適用于高度可信的環境，例如操作系統或高權限應用，resource owner向此類應用直接傳遞賬號口令，一般僅用于兼容存量的業務系統。

Client Credential Grant

適用于訪問與resource owner無關的資源，例如應用自身的圖標，配置等。

Extension Grant

自定義類型，由廠商的Authorization Server自定義，下游應用來配套，例如Google面向電視和設備應用提供的urn:ietf:params:oauth:grant-type:device_code。

準備工作

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

如下圖華為終端開發者聯盟管理中心注冊界面：

開發者進行應用注冊時，一般需要提交應用類型。應用類型常見的幾大類：

client type

說明

web application

運行在服務端的可信的web應用，用戶通過瀏覽器訪問web應用。authorization server給應用頒發的client密鑰和access token都存放在服務端，不會暴露給最終用戶。

user-agent-based application

代碼運行在客戶端的應用程序，例如瀏覽器上的單頁面應用。此類應用運行在非信任域，不能保存敏感的client密鑰。此類應用的優勢是可以充分利用客戶端的能力和authorization server交互達到無縫的訪問體驗。

native application

運行在用戶設備上的應用程序，例如手機APP，此類應用運行在非信任域，不能保存長期憑證，但可以使用臨時憑證。

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

授權碼流程

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

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

錯誤返回

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

參數名

可選/必選

說明

error

必選

錯誤標記，用于程序處理：

1. invalid_request：無效參數

2. unauthorized_client：client不允許以此方法請求授權

3. access_denied：resource owner拒絕授權

4. unsupported_response_type：不支持的response_type

5. invalid_scope：無效的授權范圍

6. server_error：authorization server報500錯誤

7. temporarily_unavailable：authorization server報503錯誤

error_description

可選

錯誤描述，可讀

error_uri

可選

錯誤信息頁面，可讀

state

必選

如果授權請求攜帶state，則必選，且原文返回

說明，所有參數需經過“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參數有差異：

redirect_uri類型

格式

示例

說明

Custom URI scheme

com.example.app:redirect_uri_path

com.googleusercontent.apps.123:/oauth2redirect

APP的scheme

Loopback IP address

http://127.0.0.1:port or http://[::1]:port

APP監聽的本地web server

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

此類場景的應用授權大致步驟如下：

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 代碼

1

{

2

"device_code":?"4/4-GMMhhdfkdkfgdgegkfkfkeegjgjgj",

3

"user_code":?"GQVQ-JKEC",

4

"verification_url":?"https://www.google.com/device",

5

"qrcode_url":?"http://www.google.com/device/qrcode\ddggheghehhhdddddddddddddddhgerhh",?? //二維碼

6

"expires_in":?1800????// code有效期

7

"interval":?5???// poll的間隔

Step3: 顯示user_code

可以屏幕顯示verification_url和user_code，甚至如果支持的話可以顯示二維碼。

Step4: poll用戶授權結果

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

-

Javascript 代碼

1

POST /token

2

Content-Type: application/x-www-form-urlencoded

3

4

client_id={client_id}&

5

client_secret={client_secret}&

6

code={device_code}&

7

grant_type=device_code

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

Step6: 處理poll 響應

-

Javascript 代碼

1

{

2

"access_token":?"1/ffffdgdg",

3

"expires_in": 3920,

4

"scope":?"openid profile email",

5

"token_type":?"Bearer",

6

"refresh_token":?"dgegegegedgegeg"

7

}

【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 參數

參數名

可選/必選

說明

response_type

必選

必須傳參為"code" 。

client_id

必選

開放認證平臺為應用分配的唯一標識。

redirect_uri

可選

應用接收認證服務端返回code的回跳地址，必須為絕對路徑，且不能包含fragment，即不能有#。

scope

可選

請求的授權范圍，由authorization server定義，例如id, profile, email等。多值通過空格分割，例如id%20profile。大小寫敏感。如果不傳，authorization server需提供默認值。

state

可選

推薦，防止CSFR攻擊，state對authorization server透明，必須原文返回，應用通過對比state防止CSRF。

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接口定義，選取幾個實踐中比較有意義的擴展參數：

參數名

可選/必選

說明

access_type

可選

推薦，取值"online"或"offline"，標識應用是否需要用戶不在線的情況下刷新access token，如果是"offline"，通過code換回token時將返回refresh_token參數，用于在用戶不在線且access token過期時輪換新的access token。

login_hint

可選

可以傳user-id快速填充登錄頁面，也可用于多會話情況下選擇合適的會話。

prompt

可選

consent: 提示用戶進行授權

select_account: 提示用戶選擇一個賬號授權

none: 不提示

1.4 響應

authorization server完成用戶身份認證并得到用戶授權后，將code作為參數重定向給redirect_uri。

參數名

可選/必選

說明

code

必選

authorization server生成，有效期非常短且一次性使用，建議有效期不超過10分鐘。code內容對于應用是透明的，且不能假設code的長度。

state

可選

如果request攜帶state參數，則必須原文返回。

2. 隱式授權請求API

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

2.1 參數

參數名

可選/必選

說明

response_type

必選

必須傳參為"token"。

client_id

必選

開放認證平臺為應用分配的唯一標識。

redirect_uri

可選

應用接收認證服務端返回access_token的回跳地址，必須為絕對路徑，且不能出現fragment，即不能包含#。

scope

可選

請求用戶的授權內容。

state

推薦

防CSRF攻擊。

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參數。

參數名

可選/必選

說明

access_token

必選

認證服務器頒發的token

【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參數。

TCP/IP web前端

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。