一、什么是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、協議流示意圖
![C:\Users\jiabao\AppData\Local\Temp\enhtmlclip\Image.png]()
-
(1)client請求用戶授權以訪問資源；
-
(2)如果用戶授權，client會接收到一個授權許可；
-
(3)client憑借授權許可及客戶端身份標識，請求access token；
-
(4)如果client身份和授權許可都認證通過，授權服務器會頒發令牌；
-
(5)client憑借訪問令牌到資源服務器請求資源；
-
(6)如果訪問令牌有效，資源服務器會回傳相應資源給client，
3、該協議流是總體概念，實際會根據使用的授權許可的型別不同而有所差異，OAuth2.0有4種授權許可型別：
授權碼從授權服務器獲得，授權服務器充當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許可型別是針對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是被高度受信任的，并且授權碼型別不能使用的場景外不建議使用，
客戶端憑證(或其它的認證形式)可以直接用作授權許可，適用于授權邊界不需要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的授權碼許可型別，支持聯合登錄和單點登錄，擁有完整的統一用戶中心體系，支持用戶登錄認證層和快取層的自定義，其詳細的時序圖如下：
聯合登錄時序圖：
![graphic]()
單點登錄時序圖：
ok,本篇就這么多內容啦~，感謝閱讀O(∩_∩)O，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/22650.html
標籤：架構設計
上一篇：聊聊spring之bean物件的實體化程序
下一篇：SpringBoot 配置
