一、什么是OAuth？
OAuth是一個授權規范，可以使A應用在受限的情況下訪問B應用中用戶的資源(前提是經過了該用戶的授權，而A應用並不需要也無法知道用戶在B應用中的賬號和密碼)，資源通常以REST API的方式暴露。
二、什么是OAuth2.0?
有2.0自然有1.0，相比1.0，2.0有如下不同：
-
授權過程比1.0更簡潔
-
全程使用https，保證安全的同時，又省去了1.0中對每個token都要加密的要求
-
2.0針對客戶端的各種類型，提出了多種獲取訪問令牌的途徑
三、為什么要用OAuth?
傳統的client-server 認證模式下，客戶端一般通過資源所有者的賬號/密碼，來向服務端請求某個受保護的資源。那么，為了能讓第三方應用訪問這些受保護的資源，資源所有者可能需要與第三方應用共享自己的賬號/密碼，但是這么做存在一些問題：
-
第三方應用需要存儲資源所有者的賬號/密碼，以便將來再次使用，並且通常會以明文的方式存儲。
-
第三方應用能訪問資源所有者全部的受保護資源，資源所有者無法約束其訪問的期限以及能夠訪問的資源邊界。
-
資源所有者無法單獨取消個別第三方應用的訪問權限，要么全部允許，要么全部不允許。
OAuth 可以解決這些問題，方法是引入一個授權層，並且將客戶端與資源所有者的角色分離。OAuth下，客戶端可以訪問哪些資源受資源所有者控制，並且客戶端的訪問憑證與資源所有者是不同的。客戶端不再使用資源所有者的憑證訪問受保護的資源，而是通過獲取一個access token（一個字符串，能夠表 示訪問的邊界，訪問的期限等訪問屬性）。在經過用戶授權后，access token會由一個授權服務器發布給第三方客戶端。然后，第三方客戶端使用access token到資源服務器訪問受保護的資源。
四、進一步理解OAuth2.0
1、OAuth中涉及的幾個角色：
-
resource owner：資源所有者,通常就是指終端用戶。
-
resource server：資源服務器,持有受保護的資源，能夠捕獲請求中的access token。
-
client：第三方應用,需訪問資源所有者受保護資源的應用。“client”在auth中只是一個術語，統指第三方應用，與該應用的執行是在服務器，桌面或其它設備上無關。
-
authorization server：授權服務器,負責頒發access token 給client，前提是client已經獲取了資源所有者的授權。
2、協議流示意圖
-
(1)client請求用戶授權以訪問資源；
-
(2)如果用戶授權，client會接收到一個授權許可；
-
(3)client憑借授權許可及客戶端身份標識，請求access token；
-
(4)如果client身份和授權許可都認證通過，授權服務器會頒發令牌；
-
(5)client憑借訪問令牌到資源服務器請求資源；
-
(6)如果訪問令牌有效，資源服務器會返回相應資源給client。
3、該協議流是總體概念，實際會根據使用的授權許可的類型不同而有所差異，OAuth2.0有4種授權許可類型：
-
Authorization Code：授權碼
授權碼從授權服務器獲得，授權服務器充當client和resource owner的中間者。client不會直接從Resource Owner請求授權，而是引導Resource Owner到授權服務器，授權服務器會反向引導Resource Owner至client，並帶上授權碼。返回授權碼之前，由授權服務器驗證Resource Owner的身份以及授權情況，因為ResourceOwner只會在授權服務器做認證，Resource Owner的憑證信息是不會讓client知曉的。授權碼在安全方面帶來了一些重要的好處，比如對客戶端認證的能力，以及避免了直接通過Resource Owner的user-agent(比如瀏覽器)來傳輸access token，使得access token對其他人不可見，包括Resource Owner自己，大大降低了access token泄露的風險。
-
Implicit：隱式
Implicit許可類型是針對clients簡化過的授權碼許可類型，在瀏覽器利用腳本語言來實現。使用Implicit類型，用戶授權后，client直接獲取一個access token，而不是獲取一個授權碼。由於沒有像授權碼一樣的中間憑證產生，所以授權許可是隱式的。由於這種特性，在某些使用瀏覽器進行URI重定向的場景下，access token可能會暴露。Implicit改善了一些clients的響應效率，但是也帶來了安全隱患，所以建議一般只在Mobile Apps等不那么容易從URI中獲取信息的應用中並且授權碼類型不可用的場景下使用。
-
Resource Owner Password Credentials：
直接使用資源所有者的密碼憑證(比如：用戶名和密碼)作為授權許可來獲取access token。該類型下雖然client知曉了Resource Owner的憑證，但是可以通過換取一個長生命周期的access token或 refresh token 來避免長期存儲憑證以便將來再次使用的需要。但是除非client是被高度受信任的，並且授權碼類型不能使用的場景外不建議使用。
-
Client Credentials：
客戶端憑證(或其它的認證形式)可以直接用作授權許可。適用於授權邊界不需要Resource Owner控制或者能夠在授權服務器預先配置的場景，比如在多個資源服務器共用統一用戶中心的場景下，資源服務器之間需要相互訪問，此時client可能也是resource owner 或者resource server。
五、如何實現OAuth2.0？
開源界有很多基於各種語言實現的OAuth2.0的框架，我們可以根據自身的需要選擇符合自己要求的框架，但是很有可能分析下來，我們會發現有些語言領域的OAuth2.0框架並不能滿足實際的需求。
比如我們只想實現類似“一處登錄，處處同行(單點登錄)；或者一個帳號多處登錄(聯合登錄，比如使用QQ、微信帳號登錄)”的特性，使用類似Spring Security OAuth就有些太重了(除非你已經再用並且非常熟悉了)，而Apache Oltu又過於粗糙，基本只提供了空架子，還要依賴它的各種包，Light OAuth2倒是很輕量，但又和undertow緊耦合，所以自研一套更輕量級的、可擴展的、適用自身業務場景的OAuth2.0框架會顯得更合適。
筆者曾花費一些時間自研了一套OAuth2.0的框架，目前只包含OAuth2.0的授權碼許可類型，支持聯合登錄和單點登錄，擁有完整的統一用戶中心體系，支持用戶登錄認證層和緩存層的自定義。其詳細的時序圖如下：
聯合登錄時序圖：
單點登錄時序圖：
ok,本篇就這么多內容啦~，感謝閱讀O(∩_∩)O。
