設(shè)計標準時，必須平衡靈活性和具體性。

譯自O(shè)Auth 2.0: A Standard in Name Only?，作者 Shon Urbas。

作為一家集成平臺公司的CTO，我花費了無數(shù)時間分析數(shù)百個SaaS應(yīng)用程序中的OAuth 2.0實現(xiàn)。雖然OAuth 2.0經(jīng)常被吹捧為標準，但現(xiàn)實情況遠比這復(fù)雜和支離破碎。

OAuth 2.0于2012年出現(xiàn)，作為OAuth 1.0的繼任者，旨在簡化網(wǎng)絡(luò)和移動應(yīng)用程序的授權(quán)流程。其目標是崇高的：

• 強制使用SSL以增強安全性
• 簡化OAuth 1.0中所需的復(fù)雜簽名過程
• 更好地支持快速普及的移動設(shè)備

理論上，OAuth 2.0將為應(yīng)用程序提供一種統(tǒng)一的方式來請求對其他系統(tǒng)上用戶帳戶的有限訪問權(quán)限，而無需共享密碼。這將使集成更安全，并更易于用戶和開發(fā)人員管理。

支離破碎的景象

然而，OAuth 2.0實現(xiàn)的現(xiàn)實情況遠非標準化。OAuth 1.0規(guī)范的作者Eran Hammer，他在OAuth 2.0發(fā)布期間著名的辭職，被引用說——“幾乎任何東西都可以很容易地被稱為符合OAuth 2.0標準”。

以下是一些關(guān)鍵問題：

1. 過度靈活：OAuth 2.0規(guī)范包含許多可選組件和流程。雖然出發(fā)點很好，但這導(dǎo)致了實現(xiàn)方式的巨大差異。
2. 復(fù)雜性：OAuth 2.0核心規(guī)范長達81頁，但要完全理解它，需要閱讀20多個附加RFC中的數(shù)千頁內(nèi)容。這種復(fù)雜性使得開發(fā)人員難以正確且一致地實現(xiàn)。
3. 實現(xiàn)不一致：主要平臺經(jīng)常偏離核心規(guī)范或以獨特的方式實現(xiàn)特定的RFC。例如：
   

a.Microsoft Azure需要用于令牌刷新的重定向URI，這不是標準規(guī)范的一部分。

b.Wix有自己的“OAuth 2解決方案”，具有非標準的“基本”和“高級”流程。要刷新高級選項，必須發(fā)送client_id和secret、訪問令牌和刷新令牌，這很不尋常。

4.安全問題：某些OAuth 2.0流程，例如資源所有者密碼憑據(jù)授權(quán)，本質(zhì)上是不安全的，但規(guī)范仍然允許。

案例研究：簽名的回歸

具有諷刺意味的是，從OAuth 1.0遷移到2.0的主要原因之一是消除對復(fù)雜簽名的需求。然而，安全問題導(dǎo)致引入了代碼交換證明密鑰（PKCE），在RFC 7636中指定。PKCE重新引入了一種類似簽名的機制來防止特定攻擊，尤其是在移動環(huán)境中。這一發(fā)展突顯了OAuth 2.0生態(tài)系統(tǒng)如何不得不發(fā)展以解決安全漏洞，有時是通過重新引入它最初試圖消除的概念。

一個很好的例子是Pleo，一家位于歐洲的費用管理公司。RFC 7636于2015年發(fā)布，Pleo是我見到的第一家使用它的公司。他們針對此用例的API是在2022年創(chuàng)建的。他們對OAuth 2.0的其余遵守情況非常好。他們遵循所有“建議”，因為他們已經(jīng)實現(xiàn)了PKCE。他們可能符合OAuth 2.1標準，但稍后再詳細介紹。

什么構(gòu)成了一個好的標準？

一個好的標準在特異性、靈活性和簡單性之間取得微妙的平衡。特異性至關(guān)重要，它通過諸如“必須”和“必需”之類的詞語提供精確的要求。然而，靈活性同樣重要，以確保在各種實現(xiàn)中得到廣泛采用。關(guān)鍵在于找到適當?shù)钠胶恻c，避免過度選擇性，這可能導(dǎo)致實現(xiàn)不一致。

簡潔性是另一個關(guān)鍵因素——一個好的標準應(yīng)該簡潔易懂。例如，OAuth 1.0 的 81 頁規(guī)范與 OAuth 2.0 散布在多個 RFC 中的數(shù)千頁形成鮮明對比，突出了復(fù)雜性如何成為一個重大缺點。最終，一個有效的標準提供了精確的強制性要求，同時允許必要的靈活性，所有這些都在一個易于理解的框架內(nèi)，不會因過多的文檔而使實施者不知所措。

認識到這些挑戰(zhàn)，OAuth 社區(qū)正在開發(fā) OAuth 2.1。此修訂旨在：

• 將最佳實踐和多個 RFC 合并到單個綜合文檔中
• 要求所有客戶端都使用 PKCE，從而全面增強安全性
• 刪除有問題的授權(quán)
• 統(tǒng)一處理公共客戶端和私有客戶端
• 強制限制刷新令牌和安全重定向

雖然 OAuth 2.1 有望解決許多當前的痛點，但它也引發(fā)了關(guān)于向后兼容性和采用時間表的問題。

對開發(fā)者和企業(yè)的影響

對于開發(fā)者和構(gòu)建集成的企業(yè)，當前的 OAuth 2.0“標準”帶來了一些挑戰(zhàn)：

1. 開發(fā)時間增加：每個 OAuth 實現(xiàn)可能需要自定義代碼，從而增加開發(fā)和維護成本。
2. 安全風險：如果不仔細管理，不一致的實現(xiàn)會導(dǎo)致安全漏洞。
3. 用戶體驗影響：OAuth 流程的變化可能會混淆最終用戶，并可能影響集成服務(wù)的采用。
4. 合規(guī)性問題：對于受監(jiān)管行業(yè)的企業(yè)而言，確保每個 OAuth 實現(xiàn)都符合安全和隱私標準可能很復(fù)雜。

結(jié)論：OAuth 2.0 是否過于靈活而無法成為標準

雖然 OAuth 2.0 提供了一個授權(quán)框架，但其當前狀態(tài)遠非一個合適的標準。過度的靈活性和碎片化導(dǎo)致了一個生態(tài)系統(tǒng)，其中“符合 OAuth 2.0”在實踐中可能意味著截然不同的東西。

當我們展望 OAuth 2.1 和像 Grant Negotiation and Authorization Protocol (GNAP) 這樣的潛在替代方案時，很明顯，對真正標準化、安全且對開發(fā)者友好的授權(quán)協(xié)議的追求仍在繼續(xù)。與此同時，開發(fā)者和企業(yè)必須保持警惕，仔細評估他們遇到的每個 OAuth 實現(xiàn)，并構(gòu)建強大的系統(tǒng)來處理各種變化。

這節(jié)課的意義超越了 OAuth：在設(shè)計標準時，平衡靈活性和特異性至關(guān)重要。過多的靈活性會導(dǎo)致碎片化，而過多的僵化會阻礙采用。隨著我們繼續(xù)構(gòu)建和連接數(shù)字系統(tǒng)，找到這種平衡將是創(chuàng)建真正有效標準的關(guān)鍵。