學習OAuth 2.0
認識OAuth 2.0
OAuth 2.0 是行業標準的授權協議。 OAuth 2.0 專註於客戶端開發人員的簡單性，同時為 Web 應用程序、桌面應用程序、移動設備提供特定的授權流程。
應用場景
有一個”雲沖印”的網站，可以將用戶儲存在Google的照片，沖印出來。用戶為了使用該服務，必須讓”雲沖印”讀取自己儲存在Google上的照片。問題是只有得到用戶的授權，Google才會同意”雲沖印”讀取這些照片。那麼，”雲沖印”怎樣獲得用戶的授權呢？
傳統方法是，用戶將自己的Google用戶名和密碼，告訴”雲沖印”，後者就可以讀取用戶的照片了。這樣的做法有以下幾個嚴重的缺點。
（1）”雲沖印”為了後續的服務，會保存用戶的密碼，這樣很不安全。
（2）Google不得不部署密碼登錄，而我們知道，單純的密碼登錄並不安全。
（3）”雲沖印”擁有了獲取用戶儲存在Google所有資料的權力，用戶沒法限制”雲沖印”獲得授權的範圍和有效期。
（4）用戶只有修改密碼，才能收回賦予”雲沖印”的權力。但是這樣做，會使得其他所有獲得用戶授權的第三方應用程序全部失效。
（5）只要有一個第三方應用程序被破解，就會導致用戶密碼泄漏，以及所有被密碼保護的數據泄漏。
OAuth就是為了解決上面這些問題而誕生的。OAuth 就是一種授權機制。數據的所有者告訴系統，同意授權第三方應用進入系統，獲取這些數據。系統從而產生一個短期的進入令牌（token），用來代替密碼，供第三方應用使用。
理解OAuth 2.0思想
- OAuth 2.0 的核心是授權許可，更進一步說就是令牌機制。也就是說，像雲沖印這樣的第三方軟件只有拿到了Google開放平台頒發的訪問令牌，也就是得到了授權許可，然後才可以代表用戶訪問他們的數據。
- 互聯網中所有的受保護資源，幾乎都是以 Web API 的形式來提供訪問的，比如某個 App 要獲取微信用戶的頭像、昵稱，雲沖印軟件要獲取用戶在Google上的照片，我們說 OAuth 2.0 與安全相關，是用來保護 Web API 的。另外，第三方軟件通過 OAuth 2.0 取得訪問權限之後，用戶便把這些權限委託給了第三方軟件，我們說 OAuth 2.0 是一種委託協議，也沒問題。
- 用訪問令牌而不是用戶名和密碼來請求用戶的數據，才大大減少了安全風險上的「攻擊面」。
OAuth 2.0 名詞解釋
（1） Third-party application：第三方應用程序，又稱”客戶端”（client），即例子中的”雲沖印”。
（2）HTTP service：HTTP服務提供商，本文中簡稱”服務提供商”，即例子中的Google。
（3）Resource Owner：資源所有者，本文中又稱”用戶”（user）。
（4）User Agent：用戶代理，本文中就是指瀏覽器。
（5）Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。
（6）Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一台服務器，也可以是不同的服務器。
OAuth 2.0 授權模式
OAuth 2.0提供了四種授權模型：授權碼模式（authorization code），簡化模式（implicit），密碼模式（resource owner password credentials），客戶端模式（client credentials）。
授權碼模式
授權碼模式工作流程如下圖所示，
（A）用戶訪問客戶端，後者將前者導向認證服務器。
（B）用戶選擇是否給予客戶端授權。
（C）假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的”重定向URI”（redirection URI），同時附上一個授權碼。
（D）客戶端收到授權碼，附上早先的”重定向URI”，向認證服務器申請令牌。這一步是在客戶端的後台的服務器上完成的，對用戶不可見。
（E）認證服務器核對了授權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。
簡化模式
簡化模式（implicit grant)工作流程如下圖所示：
（A）客戶端將用戶導向認證服務器。
（B）用戶決定是否給於客戶端授權。
（C）假設用戶給予授權，認證服務器將用戶導向客戶端指定的”重定向URI”，並在URI的Hash部分包含了訪問令牌。
（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。
（E）資源服務器返回一個網頁，其中包含的代碼可以獲取Hash值中的令牌。
（F）瀏覽器執行上一步獲得的腳本，提取出令牌。
（G）瀏覽器將令牌發給客戶端。
密碼模式
密碼模式（Resource Owner Password Credentials Grant）中，用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息，向”服務商提供商”索要授權。
在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。這通常用在用戶對客戶端高度信任的情況下，比如客戶端是操作系統的一部分，或者由一個著名公司出品。而認證服務器只有在其他授權模式無法執行的情況下，才能考慮使用這種模式。
（A）用戶向客戶端提供用戶名和密碼。
（B）客戶端將用戶名和密碼發給認證服務器，向後者請求令牌。
（C）認證服務器確認無誤後，向客戶端提供訪問令牌。
客戶端模式
客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向”服務提供商”進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以自己的名義要求”服務提供商”提供服務，其實不存在授權問題。
（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。
（B）認證服務器確認無誤後，向客戶端提供訪問令牌。
總結
本文對OAuth 2.0一些核心概念進行了基本介紹，並對四種授權模型進行了講解，提升了對OAuth 2.0的認識。
參考
//www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
//www.ruanyifeng.com/blog/2019/04/oauth_design.html
