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