OAuth2.0概念以及實現思路簡介

-Advertisement-

一、什麼是OAuth？ OAuth是一個授權規範，可以使A應用在受限的情況下訪問B應用中用戶的資源(前提是經過了該用戶的授權，而A應用並不需要也無法知道用戶在B應用中的賬號和密碼)，資源通常以REST API的方式暴露。二、什麼是OAuth2.0? 有2.0自然有1.0，相比1.0，2.0有如下不 ...

一、什麼是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種授權許可類型：

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的授權碼許可類型，支持聯合登錄和單點登錄，擁有完整的統一用戶中心體系，支持用戶登錄認證層和緩存層的自定義。其詳細的時序圖如下： 聯合登錄時序圖：

您的分享是我們最大的動力!

-Advertisement-