iT邦幫忙

2021 iThome 鐵人賽

DAY 8
1
Software Development

用Keycloak學習身份驗證與授權系列 第 8

Day07 - 【入門篇】什麼是OAuth

本系列文之後也會置於個人網站


先來回憶一下,何爲「授權」。試想像有一座宅邸,裏頭有無數房間。而你作爲這座宅邸的管家,擁有一把萬能鑰匙,可以開始宅邸內所有門扉。
此外,這把萬能鑰匙還有一個作用,就是產生出開啓特定門扉的鑰匙。
你可以產生出的鑰匙交給其他人,其他人就可以自由進出特定房間。這個動作就是「授權」。

OAuth 是一個開放標準的 授權協議 ,它允許 軟體應用 代表 資源擁有者 訪問資源擁有者的 資源 [^OAuth-2.0實戰]。

[^OAuth-2.0實戰]: OAuth 2.0實戰

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.[^RFC_6749]
OAuth 2.0 框架能讓第三方應用以有限的權限訪問HTTP服務,可以透過構建資源擁有者與HTTP服務間的許可交互機制,讓第三方應用代表資源擁有者訪問服務,或者通過授予權限給第三方應用,讓其代表自己訪問服務。[^OAuth-2.0實戰]

[^RFC_6749]: RFC 6749

作爲一個 授權框架 ,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適用於哪些場景,同樣也了解它不適用於哪些場景。

參考資料


上一篇
Day06 - 【入門篇】Keycloak的替代品
下一篇
Day08 - 【入門篇】OAuth 2.0 Playground
系列文
用Keycloak學習身份驗證與授權40

尚未有邦友留言

立即登入留言