We are not here because we are free .we are here because we are not free. 我們在這裡不是因為我們自由，我們在這裡是因為我們不自由。——《黑客帝國》 寫在開頭 在這個互聯網最美好的時代，隨著業務產品線的增多，業務應用平臺逐漸增多 ...
We are not here because we are free .we are here because we are not free.
我們在這裡不是因為我們自由，我們在這裡是因為我們不自由。——《黑客帝國》
寫在開頭
在這個互聯網最美好的時代，隨著業務產品線的增多，業務應用平臺逐漸增多後，每個系統單獨管理各自的用戶數據容易形成信息孤島，分散的用戶管理模式阻礙了企業應用向平臺化演進。當業務產品線發展到一定規模，構建統一的標準化賬戶管理體系將是必不可少的，構建一套互聯網雲平臺的重要基礎設施，能夠為平臺帶來統一的帳號管理、身份認證、用戶授權等基礎能力，為企業帶來諸如跨系統單點登錄、第三方授權登錄等基礎能力，為構建開放平臺和業務生態提供了必要條件和基本準繩。
關於OAuth授權協議的問題，也許我們中的大多數都還是從玩Github 開始的，或者就是從阮一峰的網路日誌看到的，不論是何種情況下接觸到OAuth的。我們都要相信，OAuth的正確打開方式，絕對不是三言兩語的事情，需要經過系統的分析和項目實戰，才會有不一樣的味道，不然我們遇到的都是壞味道。
OAuth授權協議
An open protocol to allow secure API authorization in a simple and standard method from web, mobile and desktop applications.
基本定義
OAuth授權協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是OAUTH的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAUTH是安全的。OAuth是Open Authorization的簡寫。
一般來說，OAuth是一個授權協議，它允許軟體應用代表（而不是充當）資源擁有者去訪問資源擁有者的資源。應用向資源擁有者請求授權，然後取得令牌（token），並用它來訪問資源，並且資源擁有者不用嚮應用提供用戶名和密碼等敏感數據。目前常用的是2.0版本，又稱為OAuth 2.0 。從官網來看，新版本2.1不久面世。
其實挑點實際話講，OAuth 2.0 並不是一門新的技術，從 2007 年 OAuth 1.0 面世，到 2011 年發佈 OAuth 2.0 草案。但是，看似簡單的 OAuth 2.0 會讓我們望而卻步，在如何使用授權碼流程上躊躇不前。比如，在 Web 應用中到底應該怎麼使用授權碼流程，移動 App 中還能使用授權碼流程嗎？
當我帶著這些問題嘗試到網上搜索資料時，那些不成體系的資料著實也讓我走了不少彎路。不知道你是不是也被下麵問題困擾著：
- 開發一個 Web 應用，當使用 OAuth 2.0 的時候，擔心授權碼被攔截，卻因為沒有較好的解決方法而一籌莫展
- 開發一款移動 App，當使用 OAuth 2.0 的時候，在確定是否需要 Server 端上，花費了大把的時間
- 開發一個小程式，當使用 OAuth 2.0 的時候，在確定是否需要 Server 端上，需要考慮的場景是否足夠多
- 開發一個面向多產品的統一授權認證平臺時，比如open-iam，對於PC平臺，後臺平臺，門戶平臺，移動端APP平臺，小程式平以及大數據監控平臺，這樣的一個需求時，當使用 OAuth 2.0 的時候，是否能實現和滿足需求
- 開發一個統一授權認證平臺，對於用戶和資源之間如何界定設置，前後端分離模式，又如何保證用戶登錄實現平臺的跳轉和通信
- 在不同架構模式背景下，對於OAuth的使用，其中的技術選型又會有怎樣的差異，更多情況下，我們的技術選型是否可取
從大方向上總結來看，OAuth 2.0 這種授權協議，就是保證第三方（軟體）只有在獲得授權之後，才可以進一步訪問授權者的數據。因此，我們常常還會聽到一種說法，OAuth 2.0 是一種安全協議。現在訪問授權者的數據主要是通過 Web API，所以凡是要保護這種對外的 API 時，都需要這樣授權的方式。而 OAuth 2.0 的這種頒發訪問令牌的機制，是再合適不過的方法了。同時，這樣的 Web API 還在持續增加，所以 OAuth 2.0 是目前 Web 上重要的安全手段之一。
基本規範
OAuth 2.0 的標準是 RFC 6749 文件。OAuth 引入了一個授權層，用來分離兩種不同的角色：客戶端和資源所有者。資源所有者同意以後，資源伺服器可以向客戶端頒發令牌。客戶端通過令牌，去請求數據。也就是說，OAuth 的核心就是向第三方應用頒發令牌。
按照一般軟體系統開發定義開看，一個 OAuth 標準應用規範都有如下幾個定義規範，或者說基本角色：
- Third-party /Client application：第三方應用端程式，一般系統平臺都稱“客戶端”（client）。代表資源擁有者訪問受保護資源的軟體，它使用OAuth 來獲取訪問許可權。
- HTTP service：HTTP服務提供商，一般系統平臺都簡稱“服務提供商”。
- Resource Owner：資源所有者，一般系統平臺都稱“用戶”（user），即登錄用戶。是有權將訪問許可權授權給客戶端的主體，在大多數情況下，資源擁有者是一個人，他使用客戶端軟體訪問受他控制的資源；
- User Agent：用戶代理，一般系統平臺就是指瀏覽器。
- Authorization server：認證伺服器，即服務提供商專門用來處理認證的伺服器。一個HTTP 伺服器，它在OAuth 系統中充當中央組件。授權伺服器對資源擁有者和客戶端進行身份認證，讓資源擁有者向客戶端授權、為客戶端頒發令牌。某些授權伺服器還會提供額外的功能，例如令牌內省、記憶授權決策
- Resource server：資源伺服器，即服務提供商存放用戶生成的資源的伺服器。它與認證伺服器，可以是同一臺伺服器，也可以是不同的伺服器。資源伺服器能夠通過HTTP 伺服器進行訪問，在訪問時需要OAuth 訪問令牌。受保護資源需要驗證收到的令牌，並決定是否響應以及如何響應請求。
這裡必須強調一點的是，這裡說的第三方，大多數指的是區別於當前應用系統的其他應用，包括不限於微信，QQ，新浪，抖音，今日頭條等等。按照正常的系統的應用來說，在所用系統之前，都會有一個類似於open-iam身份識別與訪問管理的系統的,至少來講都會有這麼一個系統組件的。這樣來說，這個IAM應用平臺在多產品業務線，甚至說是多租戶場景模式來說，這是一個系統底層架構的核心元組件，所有其他的業務應用系統，都是圍繞這個組件來進行整合和糅合其他的業務需求的，如圖所示：
其實不論在單體架構時代，還是分散式(RPC)服務時代，以及眼花繚亂微服務時代，還是現在都在追捧的雲原生架構時代，授權和認證應用模塊在日常開發里，基本上是一個框架的底層組件來構建和關聯第三方軟體以及其他應用的。互聯網中所有的受保護資源，幾乎都是以 Web API 的形式來提供訪問的。每次都是用訪問令牌而不是用戶名和密碼來請求用戶的數據，才大大減少了安全風險上的“攻擊面”，至少從系統架構層面來說，引入 OAuth 主要還是為項目架構底層保駕護航。
基本流程
在一個日常應用系統里，對於Oauth應用的系統流轉流程如下：
但是實際上，對於OAuth2 的工作原理我們通過結構化思維的拆解分析可以發現，Oauth應用的最終目的，是要獲取一個叫做“訪問令牌”的東西。在業務系統獲取到訪問令牌之後，才有足夠的 “能力” 去請求系統拿到系統給我授權的資源列表數據。不論是任何終端應用，訪問我們提供的統一授權服務，幾乎都需要依托Oauth來經歷和經過如下流程：
其中，OAuth 授權的核心就是頒發訪問令牌、使用訪問令牌。比如，業務應用系統訪問統一鑒權管控平臺，其間統一鑒權管控平臺會依據業務應用系統的需要(請求參數)，為其生成授權碼，業務應用系統拿到授權碼表示得到了授權，再次訪問統一鑒權管控平臺，後續驗證完畢生成訪問令牌，返回業務應用系統，最後業務應用系統拿到訪問令牌，去查詢對應的授權資源列表和數據，這就是使用訪問令牌。其中主要的動作，就是生成授權碼–> 生成訪問令牌–> 使用訪問令牌。其中授權碼許可（Authorization Code）類型。它是 OAuth 2.0 中最經典、最完備、最安全、應用最廣泛的許可類型。除了授權碼許可類型外，OAuth 2.0 針對不同的使用場景，還有 3 種基礎的許可類型，分別是隱式許可（Implicit）、客戶端憑據許可（Client Credentials）、資源擁有者憑據許可（Resource Owner Password Credentials）。
總結來說，OAuth 授權有 3 個關鍵點：
- OAuth 2.0 的核心是授權許可，更進一步說就是令牌機制。對於業務應用系統來說，只有拿到頒發的訪問令牌，也就是得到了授權許可，然後才可以代表用戶訪問他們的數據。
- 互聯網中所有的受保護資源，幾乎都是以 Web API 的形式來提供訪問的。我們說 OAuth 2.0 與安全相關，是用來保護 Web API 的。另外，第三方軟體通過 OAuth 2.0 取得訪問許可權之後，用戶便把這些許可權委托給了第三方軟體，我們說 OAuth 2.0 是一種委托協議，也沒問題。
- 業務應用系統對於統一鑒權管控平臺算是客戶端，統一鑒權管控平臺是服務端，而且是獨立部署服務的，每次都是用訪問令牌而不是用戶名和密碼來請求用戶的數據，才大大減少了安全風險上的“攻擊面”。
版權聲明：本文為博主原創文章，遵循相關版權協議，如若轉載或者分享請附上原文出處鏈接和鏈接來源。
