我在考虑REST Web服务API的安全性，并决定看看其他大型服务以及它们是如何做到的。作为一个例子，我决定研究Twitter的OAuth。阅读初学者指南后，我有点困惑和震惊。
据我了解，服务提供商有责任对用户进行身份验证并向用户显示消费者要求的访问权限（例如，它希望对特定资源进行只读访问）。但我看到服务提供商没有告知用户访问消费者要求的类型（甚至现在显示消费者的身份）。问题的第二部分是消费者可以在IFrame中显示自己的自定义提供者服务身份验证表单，只是隐藏访问详细信息，他们只是窃取您的密码，或者请求无限制地访问您的资源，他们基本上可以做任何他们想要的，欺骗用户有很多方法。
作为一个例子，让我们采取一个LinkedIn。他们在自己的表单中请求您的gmail用户名和密码，而您不知道他们将如何使用它。他们可以窃取它并存储在他们的数据库中，他们可以将OAuth与它一起发送到gmail（并且他们不会向gmail的页面显示他们请求的访问类型的信息），他们可以用这些信息做任何他们想做的事。
我想说的不是OAuth通信协议不安全，而是有很多方法可以不正当地使用它来欺骗用户并获取他的凭据。
BTW在OAuth协议本身存在一些安全漏洞：（http://oauth.net/advisories/2009-1/）而且我很确定还有更多，但没有人愿意找到它们。答案 0 :(得分：18)
我会选择'你不理解它'。 （在你的辩护中，很少有人这样做。）
让我们明确一点：会话固定攻击您指的是受影响的OAuth 1.0，但已在OAuth 1.0a中解决，后者变为RFC 5849。 OAuth 1.0没有主要的实现者 - 主要的实现者都实现了OAuth 1.0a / RFC 5849，或者他们实现了OAuth 2.0草案之一。
对于用户名/密码反模式，OAuth 1.0a不提供交换访问令牌的用户名和密码的机制。 OAuth 2.0可以，但仅用于支持已安装的应用程序。请记住，如果确实需要，安装的应用程序可以简单地键入（或类似）。当涉及到安全性时，如果应用程序已经在客户端的计算机上本机运行并且未经过取消装箱，那么所有的赌注都会被取消。但这实际上是一个与你所说的完全不同的场景。 OAuth 1.0a和OAuth 2.0中的Web应用程序都不会触及用户名和密码。
OAuth 1.0a的流程如下：应用程序要求提供程序提供请求令牌，告诉它所有要访问的内容。提供者发布临时未授权令牌，此时客户端可以将用户发送给提供者以授权该令牌。用户使用提供商网站上的用户名和密码登录，然后授予或拒绝访问权限。然后，提供程序将重定向回一个验证程序字符串，该字符串允许站点升级到授权的访问令牌。所有这些互动都是签名的。如果签名与其中任何签名不匹配，提供商将拒绝该请求。用户可以随时撤销任何令牌，从而消除客户访问其帐户的能力。
协议中有许多security considerations，但如果您确实阅读了该列表，则它基本上是影响互联网上几乎每个站点的安全问题列表。这些安全考虑都是众所周知的，并且非常好理解。据我所知，目前还没有针对正确解决所有这些安全考虑事项的提供商的已知可利用攻击。
重点是，使用OAuth 1.0a或OAuth 2.0来授权第三方比使用任何替代方案更安全。如果您对这些不满意，解决方案很简单：不要授权第三方访问您的帐户。肯定有很多理由说明你可能不想这样做。
答案 1 :(得分：7)
听起来你对什么不安全感到困惑。据我了解，如果实施得当，OAuth协议本身是安全的。只是它很容易实现不正确，用户会感到困惑，因为他们并不真正理解他们在做什么。
例如，LinkedIn正在做的事情都是错的。我绝不会以这种方式向他们提供我的Gmail帐户信息。为了让我能够提供我的Gmail帐户信息，我坚持看到我的浏览器正在使用SSL与Google，因此页面的根框架来自Google。
然后有一个信任谷歌的问题，正确告诉我正在请求什么访问权限以及由谁。如果我不相信他们这样做，我就不应该使用OAuth。