我最近在OAuth上做了一些工作，我不得不說我非常喜歡它。我喜歡這個概念，並且我喜歡它爲您的用戶提供了一個低限度的入口以將外部數據連接到您的網站（或者爲您提供外部消費的數據apis）。就我個人而言，我總是會拒絕那些要求我直接向他們提供我的另一個網站登錄信息的網站。 OAuth「網絡代客鑰匙」方法很好地解決了這個問題。OAuth和網絡釣魚漏洞是否被無情地捆綁在一起？
我（和許多其他人）看到的最大問題是，標準的OAuth工作流程鼓勵釣魚攻擊對他們有利的相同類型的行爲。如果您訓練用戶認爲正常行爲被重定向到提供登錄憑據的站點，那麼釣魚網站很容易利用這種正常行爲，而是將其重定向到他們的克隆網站，並在其中捕獲您的用戶名和密碼。
什麼，如果有的話，你做了（或看到完成），以緩解這個問題？
您是否告訴用戶手動登錄到提供站點，而無需自動鏈接或重定向？ （但是這會增加進入的障礙）
您是否嘗試教育您的用戶，如果是，何時以及如何進行教育？用戶必須閱讀的關於安全性的任何冗長的解釋也增加了進入的障礙。
還有什麼？
延長代客類比：你怎麼知道你可以信任代客，而且他/她不僅僅是一個人試用它？你並不是真正的：你只是根據上下文做出這種（或許是無意識的）判斷：你知道酒店，你曾經有過，你甚至可以認出你給你鑰匙的人。
以同樣的方式，當您使用OAuth（或OpenID）登錄時，您將用戶重定向到他們應該熟悉的站點/ URL，看到他們從該站點提供其已知的憑據給他們。
我相信OAUth和網絡釣魚他們是無情地聯繫起來的，至少在OAuth目前的形式下。已經有系統來阻止網絡釣魚，最顯着的HTTPs（暫停笑聲......），但顯然它不起作用。
網絡釣魚是針對需要用戶名/密碼組合的系統的非常成功的攻擊。只要用戶使用用戶名和密碼進行身份驗證，網絡釣魚永遠是個問題。更好的系統是使用非對稱密碼進行認證。所有現代瀏覽器都支持智能卡。您不能釣到坐在某人錢包中的卡，並且竊取用戶的桌面不會泄露私鑰。不對稱密鑰對不一定要在智能卡上，但我認爲它構建了一個比純粹用軟件實現的系統更強大的系統。
這不僅僅是一個OAuth問題，它也是OpenID的問題。更糟糕的是，當你使用OpenID的時候，你會給你的提供者一個網站，如果你還沒有一個虛假的網站，那麼很容易就自動地抓取這個網站，並且生成一個你直接指引你的用戶。
幸運的是，沒有什麼嚴重的使用OpenID進行身份驗證 - 博客文章，flickr評論只是不是一個多汁的目標。
現在，當OpenID開始開發他們的信息卡支持時，他們正在進行緩解，其中一個固定的UI形式的客戶端軟件將提供安全的身份「錢包」，但MS似乎已經放棄了儘管它們是（開放的）規範，但是它們會在信息卡上自己發球。
它不會很快消失。
什麼，以證明該OAuth的提供商就像SSL認證？只有認證的oAuth供應商值得信賴。但問題是，與ssl認證一樣，CA也很重要。
你必須與你將被重定向到，不應該被他們實施反釣魚措施的網站的帳戶，如簽名短語和形象？這也利用了用戶從例如通常使用這些措施的銀行。
在一般情況下，登錄頁應提供用戶友好的共享祕密給用戶，以確認他們是登錄到該網站的身份。
正如Jingle所說，ssl證書可用於身份驗證，但在這種情況下，用戶無法直接從站點將證書作爲OAuth安裝過程的一部分加載到其Web瀏覽器中？如果已經與該網站建立了信任關係，我不確定是否需要進一步訴諸CA。
有一些技術，可以用來避免或減少網絡釣魚攻擊。我做了一個便宜的選項列表：
高度以上列出的所有選項取決於對信息安全和隱私的用戶教育。僅在第一次身份驗證時纔出現的嚮導可以幫助實現此目標。
該網站應該知道他們，但是這是如何工作的釣魚 - 他們創造一個看起來像我克隆。我想最終取決於用戶是否聰明，但是盡我們所能來緩解這些問題可能會有一段很長的路要走。我只是不知道我們可以爲OAuth /網上誘騙做些什麼...... – Matt 2010-02-01 20:52:30