認識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的認識。
參考
https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html