OAuth 2.0：徒有虛名？
設計標準時，必須平衡靈活性和具體性。
譯自OAuth 2.0: A Standard in Name Only?，作者 Shon Urbas。
作為一家集成平臺公司的CTO，我花費了無數時間分析數百個SaaS應用程序中的OAuth 2.0實現。雖然OAuth 2.0經常被吹捧為標準，但現實情況遠比這復雜和支離破碎。
OAuth 2.0于2012年出現，作為OAuth 1.0的繼任者，旨在簡化網絡和移動應用程序的授權流程。其目標是崇高的：
- 強制使用SSL以增強安全性
- 簡化OAuth 1.0中所需的復雜簽名過程
- 更好地支持快速普及的移動設備
理論上，OAuth 2.0將為應用程序提供一種統一的方式來請求對其他系統上用戶帳戶的有限訪問權限，而無需共享密碼。這將使集成更安全，并更易于用戶和開發人員管理。
支離破碎的景象
然而，OAuth 2.0實現的現實情況遠非標準化。OAuth 1.0規范的作者Eran Hammer，他在OAuth 2.0發布期間著名的辭職，被引用說——“幾乎任何東西都可以很容易地被稱為符合OAuth 2.0標準”。
以下是一些關鍵問題：
- 過度靈活：OAuth 2.0規范包含許多可選組件和流程。雖然出發點很好，但這導致了實現方式的巨大差異。
- 復雜性：OAuth 2.0核心規范長達81頁，但要完全理解它，需要閱讀20多個附加RFC中的數千頁內容。這種復雜性使得開發人員難以正確且一致地實現。
- 實現不一致：主要平臺經常偏離核心規范或以獨特的方式實現特定的RFC。例如：
a.Microsoft Azure需要用于令牌刷新的重定向URI，這不是標準規范的一部分。
b.Wix有自己的“OAuth 2解決方案”，具有非標準的“基本”和“高級”流程。要刷新高級選項，必須發送client_id和secret、訪問令牌和刷新令牌，這很不尋常。
4.安全問題：某些OAuth 2.0流程，例如資源所有者密碼憑據授權，本質上是不安全的，但規范仍然允許。
案例研究：簽名的回歸
具有諷刺意味的是，從OAuth 1.0遷移到2.0的主要原因之一是消除對復雜簽名的需求。然而，安全問題導致引入了代碼交換證明密鑰（PKCE），在RFC 7636中指定。PKCE重新引入了一種類似簽名的機制來防止特定攻擊，尤其是在移動環境中。這一發展突顯了OAuth 2.0生態系統如何不得不發展以解決安全漏洞，有時是通過重新引入它最初試圖消除的概念。
一個很好的例子是Pleo，一家位于歐洲的費用管理公司。RFC 7636于2015年發布，Pleo是我見到的第一家使用它的公司。他們針對此用例的API是在2022年創建的。他們對OAuth 2.0的其余遵守情況非常好。他們遵循所有“建議”，因為他們已經實現了PKCE。他們可能符合OAuth 2.1標準，但稍后再詳細介紹。
什么構成了一個好的標準？
一個好的標準在特異性、靈活性和簡單性之間取得微妙的平衡。特異性至關重要，它通過諸如“必須”和“必需”之類的詞語提供精確的要求。然而，靈活性同樣重要，以確保在各種實現中得到廣泛采用。關鍵在于找到適當的平衡點，避免過度選擇性，這可能導致實現不一致。
簡潔性是另一個關鍵因素——一個好的標準應該簡潔易懂。例如，OAuth 1.0 的 81 頁規范與 OAuth 2.0 散布在多個 RFC 中的數千頁形成鮮明對比，突出了復雜性如何成為一個重大缺點。最終，一個有效的標準提供了精確的強制性要求，同時允許必要的靈活性，所有這些都在一個易于理解的框架內，不會因過多的文檔而使實施者不知所措。
認識到這些挑戰，OAuth 社區正在開發 OAuth 2.1。此修訂旨在：
- 將最佳實踐和多個 RFC 合并到單個綜合文檔中
- 要求所有客戶端都使用 PKCE，從而全面增強安全性
- 刪除有問題的授權
- 統一處理公共客戶端和私有客戶端
- 強制限制刷新令牌和安全重定向
雖然 OAuth 2.1 有望解決許多當前的痛點，但它也引發了關于向后兼容性和采用時間表的問題。
對開發者和企業的影響
對于開發者和構建集成的企業，當前的 OAuth 2.0“標準”帶來了一些挑戰：
- 開發時間增加：每個 OAuth 實現可能需要自定義代碼，從而增加開發和維護成本。
- 安全風險：如果不仔細管理，不一致的實現會導致安全漏洞。
- 用戶體驗影響：OAuth 流程的變化可能會混淆最終用戶，并可能影響集成服務的采用。
- 合規性問題：對于受監管行業的企業而言，確保每個 OAuth 實現都符合安全和隱私標準可能很復雜。
結論：OAuth 2.0 是否過于靈活而無法成為標準
雖然 OAuth 2.0 提供了一個授權框架，但其當前狀態遠非一個合適的標準。過度的靈活性和碎片化導致了一個生態系統，其中“符合 OAuth 2.0”在實踐中可能意味著截然不同的東西。
當我們展望 OAuth 2.1 和像 Grant Negotiation and Authorization Protocol (GNAP) 這樣的潛在替代方案時，很明顯，對真正標準化、安全且對開發者友好的授權協議的追求仍在繼續。與此同時，開發者和企業必須保持警惕，仔細評估他們遇到的每個 OAuth 實現，并構建強大的系統來處理各種變化。
這節課的意義超越了 OAuth：在設計標準時，平衡靈活性和特異性至關重要。過多的靈活性會導致碎片化，而過多的僵化會阻礙采用。隨著我們繼續構建和連接數字系統，找到這種平衡將是創建真正有效標準的關鍵。
