隨手扎
【用Keycloak學習身份驗證與授權07】什麼是OAuth
先來回憶一下，何爲「授權」。試想像有一座宅邸，裏頭有無數房間。而你作爲這座宅邸的管家，擁有一把萬能鑰匙，可以開始宅邸內所有門扉。 此外，這把萬能鑰匙還有一個作用，就是產生出開啓特定門扉的鑰匙。 你可以產生出的鑰匙交給其他人，其他人就可以自由進出特定房間。這個動作就是「授權」。
OAuth 是一個開放標準的 授權協議 ，它允許 軟體應用 代表 資源擁有者 訪問資源擁有者的 資源 1。
OAuth是什麼？
OAuth 2.0 是一個授權協議,它允許軟體應用代表(而不是充當)資源擁有者去訪問資源擁 有者的資源。應用向資源擁有者請求授權,然後取得令牌(token),並用它來訪問資源。這一切 都不需要應用去充當資源擁有者的身份,因為令牌明確表示了被授予的訪問權。
– OAuth 2.0 實戰
眾所周知，OAuth是一個安全協議，協議規範是這樣定義的：
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.2
OAuth 2.0 框架能讓第三方應用以有限的權限訪問HTTP服務，可以透過構建資源擁有者與HTTP服務間的許可交互機制，讓第三方應用代表資源擁有者訪問服務，或者通過授予權限給第三方應用，讓其代表自己訪問服務。1
作爲一個 授權框架 ，OAuth關注的是如何讓一個系統組件獲取對另一個系統組件的訪問權限。我們需要關心如下組件：
- 資源擁有者 能將訪問授權委託出去。
資源擁有者指的是使用者本身，或在系統中的帳號。起初的OAuth設計是基於HTTP的，所以可以理解爲坐在瀏覽器前的人。
或是本節一開始舉的例子–宅邸的管家–。將訪問授權委託出去的過程，就是利用萬能鑰匙產生出其他有限鑰匙並轉交他人的過程。 - 某種受保護資源 。 OAuth並不關心受保護資源長什麼樣子，可能是個RESTfule API、某個頁面、URI所識別的其他種類資源。 就像是宅邸裡每一個房間。
- 客戶端 。 還記得在「快速開始」建立的「my-quick-start-app」嗎？客戶端指的就是代表資源擁有者訪問受保護資源的軟體。 也就是將產生出的鑰匙轉交給「他人」。
OAuth 不是什麼？
- OAuth 不是身份驗證協議 。
雖然可以基於OAuth進行身份驗證，就如同在「快速開始」的例子。但其關注的重點仍在授權而非身份驗證。 - OAuth 沒有定義用戶對用戶的授權機制 。
同樣不是不行，但它根本上是一個用戶向應用軟體授權的協議。它甚至不關注存取控制。 - OAuth 沒有定義授權處理機制。
雖然OAuth定義了一些授權框架/流程，但不定義授權的內容。相反，由服務API定義使用授權範圍，允許權杖適合哪些操作。 - OAuth 沒有定義權杖格式。
OAuth協議明確申明了權杖的內容對於客戶端是完全不透明的。雖然權杖本身對於客戶端是不透明的，但接受權杖處理的服務，仍然需要理解權杖。 換句話說授權伺服器產生權杖，但對於權杖的理解全依賴於資源伺服器。
同本節一開始的例子，萬能鑰匙產生了新的房門鑰匙。但這把鑰匙實際能不能夠使用，由門鎖直接決定。與拿到鑰匙的人、管家沒有直接關係。 - OAuth 2.0 沒有定義加密方法
儘管爲了安全，諸多服務如Google、Spofity都會要求客戶端支援HTTPS。但框架本身同樣不關注這部分，也不管權杖如何簽名、加密、驗證。 - OAuth 2.0 不是單體協議。
從上述來看，該規範被分成多個定義和流程，每個定義和流程都有各自適用的場景。
OAuth 2.0 規範定義了一個授權協議，用戶在Web應用以及API之間傳遞授權決策。因爲OAuth 2.0用於獲取已經通過身份驗證的最終用戶的許可，所以很多開發人員和API服務商認爲OAuth 2.0是一種讓用戶安全登入的身份認證協議。然後，儘管OAuth 2.0是宜個需要用戶交互的安全協議，但並不是身份認證協議。我門要明確地重申一遍：
OAuth 2.0 不是身份認證協議。
之所以會產生如此多的誤解，是因爲OAuth 2.0經常被用於身份認證協議內部，而常規的OAuth 2.0流程內部也會包含一些身份驗證事件。所以，很多開發人員看到這樣的OAuth 2.0流程，以爲使用OAuth就是執行身份驗證。這種想法不僅是錯誤的，而且會給服務提供商、開發人員和最終用戶帶來危險。
– OAuth 2.0 實戰
OAuth 1.0
開發人員試圖發明一個協議，允許用戶將API訪問授權出去。新的協議基於多個具有同樣思想的專有實現，包括Google的AuthSub以及Yahoo!的BBAuth。在這些實現中，客戶端應用只要獲得用戶的授權並得到一個權杖，就能夠使用這個權杖訪問遠端API。這些權杖的發放都包含公共和私有的部份，並且該協議使用了一種新型的(現在看來是脆弱的)加密簽名機制，使得它可以在非TLS HTTP連接上使用。他們稱為這個協議為OAuth 1.0，並將其作為一項Web開放標準發布，它很快獲得響應，出現了多種語言對這一標準的自由實現。這一標準表現優秀，深得開發人員喜愛，甚至一些大型網路公司也很快棄用了自己的專有機制，起初正是這些專有機制啟發了OAuth。
– Justin Richer
OAuth 2.0 並不相容於 OAuth 1.0 。但相關概念最早始於2006年11月。現在看到的OAuth應該大多都直接是指 OAuth 2.0 。在2009年4月30日。 OAuth 1.0 被發現一個安全漏洞。同樣地， OAuth 2.0 可能也不是一個完美的協議，但從現實層面來看，今天的它非常流行，以至於開發者幾乎不能不知道。
OAuth碳 (OAuth-tan)
除了由Chris Messina繪製並提交給社區OAuth的公共汽車乘車幣標誌。OAuth協議甚至還有一個超級酷的非官方吉祥物： OAuth碳 (OAuth-tan)
結語
OAuth 無意用一個大而全的協議去解決安全系統所有方面的問題,而是只專註於一件事情, 把剩下的問題留給其他組件,讓它們各專所長。
– OAuth 2.0 實戰
就是因爲這樣專注一件事，刻意糢糊部分，所以OAuth有非常高的彈性，適用於多種不同情境。但也相對的並不那麼容易理解，且實踐過程中還有可能踩入反模式，反而照成威脅。
OAuth是一個非常強大的工具，它的強大來自其靈活性，靈活性通常意味著它不僅能夠完成你的構想，而且也會帶來安全問題。OAuth管理API的訪問權限，守護著重要資料，所以最關鍵的是避免反模式，運用最佳實踐，以安全的方式使用它。換句話說，雖然它的靈活性能讓你可以以任何方式使用和部署它，但並不意味著你應該那樣隨意。
關於OAuth，還有一件要提到的事情——你不是為了用OAuth而去用它。你是想用它來做一些別的事情——很可能是要將一組API調用精心組合起來，以實現一個絕妙的點子。你或許正在頭腦中勾勒遺符完整的圖景，正思考如何實現自己的傑作。OAuth可以幫助你以更安全的方式實現它。
—-Ina Glazer, Saleforce公司身份管理高級總監
我們也差不多到入門篇的尾聲了，但我會強力建議你繼續閱讀之後的內容。畢竟：
與所有工具一樣，了解工具的工作原理及其優點非常重要。畢竟，用錘子雖然可以將螺絲釘打入牆壁，但用螺絲刀可能會更省力。希望你了解OAuth適用於哪些場景，同樣也了解它不適用於哪些場景。
參考資料
- OAuth 2.0 實戰
- 維基百科-開放授權(OAuth)
