摘要：OAuth是一種授權協議，允許用戶在不將賬號口令泄露給第三方應用的前提下，使第三方應用可以獲得用戶在某個web服務上存放資源的訪問權限。
背景
在傳統模式下，用戶的客戶端在訪問某個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的幾種模式，應用場景，交互過程以及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。