我最近一直在使用 OAuth 做一些工作，我不得不说我真的很喜欢它。我喜欢这个概念，我喜欢它如何为您的用户提供一个低门槛，以便将外部数据连接到您的站点（或为您提供数据 api 以供外部使用）。就个人而言，我一直对要求我直接向他们提供另一个网站的登录信息的网站犹豫不决。OAuth“网络代客密钥”方法很好地解决了这个问题。
不过，我（和许多其他人）看到的最大问题是标准 OAuth 工作流程鼓励使用网络钓鱼攻击对其有利的相同类型的行为。如果您训练您的用户将重定向到站点以提供登录凭据是正常行为，那么网络钓鱼站点很容易利用该正常行为，而是重定向到他们捕获您的用户名和密码的克隆站点。
如果有的话，你做了什么（或看到做了什么）来缓解这个问题？
您是否告诉用户手动登录提供站点，而不使用自动链接或重定向？（但这增加了进入的门槛）
您是否尝试教育您的用户，如果是，何时以及如何教育？用户必须阅读的任何冗长的安全解释也会增加进入的门槛。
还有什么？
我相信 OAUth 和网络钓鱼是不可分割的，至少在 OAuth 目前的形式中是这样。已经有系统可以防止网络钓鱼，最引人注目的 HTTPs（停顿一下……），但显然它不起作用。
网络钓鱼是针对需要用户名/密码组合的系统的非常成功的攻击。只要人们使用用户名和密码进行身份验证，网络钓鱼就永远是个问题。更好的系统是使用非对称加密进行身份验证。所有现代浏览器都内置了对智能卡的支持。您无法通过网络钓鱼攻击某人钱包中的卡，并且入侵用户的桌面不会泄露私钥。非对称密钥对不必在智能卡上，但我认为它构建了一个比纯粹用软件实现的系统更强大的系统。
您在被重定向到的站点上有一个帐户，他们不应该实施诸如签名短语和图像之类的反网络钓鱼措施吗？这也利用了用户从通常使用这些措施的银行等机构接受的任何现有培训。
一般来说，登录页面应该向用户提供用户友好的共享机密，以确认他们正在登录的站点的身份。
正如 Jingle 所指出的，ssl 证书可用于身份验证，但在这种情况下，作为 OAuth 设置过程的一部分，用户不能直接从站点将证书加载到他们的 Web 浏览器中吗？如果已经与站点建立了信任关系，我不确定是否有必要进一步求助于 CA。
有一些技术可用于避免或减少网络钓鱼攻击。我列出了便宜的选择：
上面列出的所有选项都高度依赖于用户对信息安全和隐私的教育。仅在第一次身份验证时出现的向导可以帮助实现这一目标。
延伸代客的类比：你怎么知道你可以信任代客，并且他/她不仅仅是试穿的人？你不是真的：你只是根据上下文做出那个（也许是无意识的）判断：你知道这家酒店，你以前去过那里，你甚至可能认出你正在给谁钥匙的人。
同样，当您使用 OAuth（或 OpenID）登录时，您会将用户重定向到他们应该熟悉的站点/URL，因为他们正在从他们知道的那个站点提供他们的凭据。
这不仅仅是 OAuth 问题，也是 OpenID 的问题。当然，使用 OpenID 更糟糕的是，您将网站提供给您的提供商，如果您还没有伪造的网站，很容易自动抓取该网站并生成一个然后您也可以引导您的用户。
幸运的是，没有什么严肃的事情使用 OpenID 进行身份验证——博客文章、flickr 评论并不是一个有趣的目标。
现在 OpenID 在开始开发他们的信息卡支持时正在采取缓解措施，其中客户端软件形式的固定 UI 将提供一个安全的身份“钱包”，但 MS 似乎已经放弃了自己的信息卡卡片，即使这是他们的（开放）规范。
它不会很快消失。
如何像 ssl 认证一样认证 oAuth 提供者？只有经过认证的 oAuth 提供商才值得信赖。但问题是，与 ssl 认证一样，CA 很重要。