在最近的五年間，復(fù)合應(yīng)用程序已經(jīng)從新奇的事物變成了主流。在構(gòu)建復(fù)合應(yīng)用程序時，關(guān)鍵的架構(gòu)問題之一就是在訪問特定服務(wù)的時候需要雙重認(rèn)證，以及相關(guān)的認(rèn)證規(guī)則： 一般，我們需要對觸發(fā)服務(wù)的（復(fù)合）應(yīng)用程序和復(fù)合應(yīng)用程序本身的用戶進行認(rèn)證，同時還要能夠為應(yīng)用程序和用戶定義服務(wù)訪問規(guī)則。這在客戶端/服務(wù)器中間件環(huán)境中尤其困難，包括HTTP環(huán)境，因為多年以來它們構(gòu)建的前提就是“客戶端”只會表現(xiàn)為單一的標(biāo)識：或者是軟件客戶端，或者是用戶，而不能二者都是。
現(xiàn)在典型的復(fù)合應(yīng)用程序會使用流行的API（像Twitter、Facebook或者Google），通過這些API它會請求對用戶特定的數(shù)據(jù)進行訪問。之前，復(fù)合應(yīng)用程序的開發(fā)者需要了解針對每項服務(wù)的用戶證書，那樣才能夠訪問他們的數(shù)據(jù)并以字母順序的方式將它們混合在一起。Jeff Altwood曾經(jīng)用一種情況與這個過程做過比較，那種情況是和某人要房間的鑰匙，目的只是要獲得通訊簿。2007年四月，一小組人創(chuàng)建了OAuth項目，初始成員包括Blaine Cook、Chris Messina、Larry Halff 和David Recordon。
OAuth是位于HTTP和HTTPS上層的協(xié)議，它讓復(fù)合應(yīng)用程序和服務(wù)的用戶都可以為服務(wù)和應(yīng)用程序賦予部分訪問權(quán)限。它基于第三方的信任聯(lián)盟：用戶-應(yīng)用程序、用戶-服務(wù)和應(yīng)用程序-服務(wù)。 這個組織很快就發(fā)布了OAuth 1.0規(guī)范，人們也開始使用它。OAuth 1.0可能發(fā)布地太快了，因此廣受批評。之后很快就出現(xiàn)了與之競爭的WRAP（Web資源授權(quán)協(xié)議），它很快地進行了標(biāo)準(zhǔn)化，成為OAuth的對手。從那時開始，OAuth工作小組就開始著手創(chuàng)建OAuth 2.0。
OAuth最明顯的便利性在于，Twitter在本月（2010年9月）決定對訪問它的API實行強制認(rèn)證，然后不再支持基本的認(rèn)證方式。Michael Calore解釋說：
Twitter的這個舉措反映出在社會化網(wǎng)絡(luò)的更廣泛的趨勢，其中當(dāng)服務(wù)和應(yīng)用程序與用戶的賬號連接的時候，基本的認(rèn)證需要擴展為更安全的OAuth。
包括iCodeBlog在內(nèi)的很多網(wǎng)站都提供了教程，幫助開發(fā)者快速地更新他們的應(yīng)用程序。并且，即便OAuth還處于草稿階段，它已經(jīng)得到了Facebook的支持，它已經(jīng)預(yù)定是OAuth協(xié)議最大的實現(xiàn)者，并且是該規(guī)范的關(guān)鍵利益相關(guān)者。
看起來這次業(yè)界已經(jīng)對解決這個重要的問題達(dá)成了廣泛的共識。然而，OAuth 2.0的一位制定者，同時也是OAuth早期的貢獻者Eran Hammer-Lahav突然離開了這個工作組，并在離開之前發(fā)布了關(guān)于這個規(guī)范的最新方向的批評意見，認(rèn)為規(guī)范因為“不記名的令牌（bearer tokens）”而放棄了數(shù)字簽名和加密。然而，Eran自己也承認(rèn)，“加密是不可原諒的”。開發(fā)者很容易在對消息加密或者簽名的步驟中犯錯，并且一般這是不可原諒的錯誤。放棄加密是WRAP的初始想法的一部分：
在WRAP架構(gòu)的核心有一種需求，就是要從客戶端移除所有加密。WRAP的作者發(fā)現(xiàn)，開發(fā)者因為OAuth 1.0中的數(shù)字簽名而痛苦掙扎，他們的結(jié)論是，完全放棄數(shù)字簽名是最好的解決方案。取而代之的是，他們決定依賴于已經(jīng)得到驗證的并且廣泛可用的技術(shù)：HTTPS（或者更準(zhǔn)確地說是SSL/TLS）。如果開發(fā)者可以在他們的請求中添加一個字符（將http://更改為https://）就可以保護自己的秘密不被竊聽者得到，為什么要使用數(shù)字簽名呢？后續(xù)的批評大多是集中于WRAP并非真的需要HTTPS上。這只是提供了一種選擇。 這種對沒有秘密的令牌或者其它驗證機制的使用被叫做不記名令牌（這與cookie類似）。所有持有令牌的人都會獲得訪問權(quán)限。如果你是攻擊者，那么只需要持有這個簡單的字符串，就可以來去自如。不需要任何數(shù)字簽名、計算、反向工程，或者類似的方法。
這個模型的支持者的觀點如下： 既然大多數(shù)服務(wù)都使用基于cookie的認(rèn)證系統(tǒng)，那么使用額外的機制也不會更安全，因為攻擊者總會把目標(biāo)定在最脆弱的地方。實際上，Eran的擔(dān)心不是關(guān)于當(dāng)前的OAuth的，而是關(guān)于這個規(guī)范將在五年之內(nèi)所產(chǎn)生的影響，那時肯定會需要更安全的協(xié)議。首先，論點再次提到，由于OAuth 2.0是最脆弱的環(huán)節(jié)，就沒有必要實現(xiàn)更強壯的安全機制。其次，OAuth能夠在當(dāng)前的環(huán)境中工作的原因就在于，所有API都針對客戶端做了很好的簽名，并且大多數(shù)API終端都是在客戶端代碼或配置中靜態(tài)聲明的，在應(yīng)用程序發(fā)布之前都得到了徹底的測試。因此總的來說，幾乎沒有將這個令牌發(fā)送到不友好的目標(biāo)站點的風(fēng)險。
《RESTful Web Services Cookbook》一書的作者Subbu Allamaraju在個人筆記中寫到：
如果客戶端應(yīng)用程序向錯誤的地址發(fā)送請求（比方說“mail.exmple.org”而不是“mail.example.org”），位于“mail.exmple.com”惡意服務(wù)器就會得到客戶端的訪問令牌，并可以訪問它的郵件。當(dāng)然，對于瀏覽器的情況，瀏覽器開發(fā)者應(yīng)該負(fù)責(zé)不要通過實現(xiàn)相同的原始策略而泄漏cookie。OAuth2.0客戶端開發(fā)者也有同樣的責(zé)任。
然而，Eran還是認(rèn)為Web應(yīng)該更安全，那樣才能夠支持更加動態(tài)的情況，并且支持通過各種服務(wù)實現(xiàn)的標(biāo)準(zhǔn)API的世界：
一旦我們試圖通過服務(wù)引入可發(fā)現(xiàn)或者互操作的API，OAuth 2.0就會出現(xiàn)故障。因為它缺少對令牌的加密保護（沒有任何令牌秘密），客戶端需要指出向哪里發(fā)送令牌才是安全的。OAuth依賴于cookie模型來獲得相同的解決方案——讓客戶端來應(yīng)用安全策略，并指出和哪些服務(wù)器共享它的令牌。當(dāng)然，資源服務(wù)器能夠請求任何授權(quán)服務(wù)器所發(fā)布的令牌。例如，受保護的資源可以聲稱，它需要Google發(fā)布的OAuth訪問令牌，事實上此時是與Google無關(guān)的（即便它可能是Google的子領(lǐng)域服務(wù)）。 客戶端需要指出，服務(wù)器是否被授權(quán)能夠看到它的Google訪問令牌。Cookie擁有關(guān)于哪個cookie與哪臺服務(wù)器共享的規(guī)則。但是，因為這些規(guī)則是由客戶端執(zhí)行的，所以長久以來的問題是，對cookie的錯誤共享會產(chǎn)生安全性的故障。對于OAuth 2.0也是一樣。
他做出這樣的結(jié)論：
任何基于客戶端執(zhí)行安全策略的解決方案都會被打破，并出現(xiàn)故障。OAuth 1.0通過支持?jǐn)?shù)字簽名來解決這個問題。如果客戶端向錯誤的服務(wù)器發(fā)送了請求，什么危險的事情都不會發(fā)生，因為惡意服務(wù)器沒有任何方法使用那個錯誤導(dǎo)向的請求來做任何事。如果客戶端向錯誤的服務(wù)器（通過發(fā)現(xiàn)找到的）發(fā)送OAuth 2.0請求，那臺服務(wù)器就可以自由訪問用戶的資源，因為令牌是有效的。
沒有發(fā)現(xiàn)機制，較小的公司想要讓他們的服務(wù)可以訪問，需要花費大量的時間。
復(fù)合應(yīng)用程序快速成為關(guān)鍵的變革方向，它為簡單的數(shù)據(jù)——像任務(wù)、朋友或者TV指南——添加了新的價值。同時，OAuth對快速地采用做出了平衡，因為它解決了嚴(yán)重的問題，并在業(yè)界得到了一些動力，比方說Facebook和Twitter對它的支持。 和經(jīng)常在標(biāo)準(zhǔn)化過程中所發(fā)生的一樣，我們現(xiàn)在處于十字路口，我們的業(yè)界需要選擇這條路，或者是那條路：我們是要支持更簡單的安全機制，從而讓大量開發(fā)者能夠創(chuàng)建這些復(fù)合應(yīng)用程序呢？還是應(yīng)該實現(xiàn)更強壯的機制，那會讓其他開發(fā)者創(chuàng)建更多與現(xiàn)存的服務(wù)交互和競爭的服務(wù)呢？你站在哪一邊呢？
