OAuth 授權協議 | 都云原生時代了，我們應該多懂一點OAuth ？

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 中還能使用授權碼流程嗎？
當我帶著這些問題嘗試到網上搜索資料時，那些不成體系的資料著實也讓我走了不少彎路，不知道你是不是也被下面問題困擾著：

1. 開發一個 Web 應用，當使用 OAuth 2.0 的時候，擔心授權碼被攔截，卻因為沒有較好的解決方法而一籌莫展
2. 開發一款移動 App，當使用 OAuth 2.0 的時候，在確定是否需要 Server 端上，花費了大把的時間
3. 開發一個小程式，當使用 OAuth 2.0 的時候，在確定是否需要 Server 端上，需要考慮的場景是否足夠多
4. 開發一個面向多產品的統一授權認證平臺時，比如open-iam，對于PC平臺，后臺平臺，門戶平臺，移動端APP平臺，小程式平以及大資料監控平臺，這樣的一個需求時，當使用 OAuth 2.0 的時候，是否能實作和滿足需求
5. 開發一個統一授權認證平臺，對于用戶和資源之間如何界定設定，前后端分離模式，又如何保證用戶登錄實作平臺的跳轉和通信
6. 在不同架構模式背景下，對于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 訪問令牌，受保護資源需要驗證收到的令牌，并決定是否回應以及如何回應請求，

其實不論在單體架構時代，還是分布式(RPC)服務時代，以及眼花繚亂微服務時代，還是現在都在追捧的云原生架構時代，授權和認證應用模塊在日常開發里，基本上是一個框架的底層組件來構建和關聯第三方軟體以及其他應用的，互聯網中所有的受保護資源，幾乎都是以 Web API 的形式來提供訪問的，每次都是用訪問令牌而不是用戶名和密碼來請求用戶的資料，才大大減少了安全風險上的“攻擊面”，至少從系統架構層面來說，引入 OAuth 主要還是為專案架構底層保駕護航，

著作權宣告：本文為博主原創文章，遵循相關著作權協議，如若轉載或者分享請附上原文出處鏈接和鏈接來源，

標籤：架構設計

上一篇：Spring Cloud 2021.0.1 移除了Hystrix、Zuul等Netflix組件

下一篇：戲說領域驅動設計（廿一）——領域服務