那么首先要考虑的是SSL/TLS 是绝对必要的正确实施。

还必须考虑 2-legged 或 3-legged 身份验证机制。虽然大多数人会推荐更复杂（和安全）的 3-legged 方法，但对于某些应用程序， 2-legged 可能会具有优势。

rootlabs在 OAuth上发现了一些定时攻击。XSS/CSRF和ClickJacking （以及其他针对 authn 的攻击）也存在风险，就像在任何 Web 应用程序中一样。

ArsTechnica 发表了两篇关于OAuth 安全架构的文章，其中一篇链接自Bruce Schneier。

我没有足够的积分发表评论，所以我添加了这个作为答案。OAuth 首先是一种授权协议，而不是主要的身份验证。即使身份验证嵌入在协议中，它也不是主要目的。

OAuth 1.0a 在移动和桌面应用程序中的最大问题是用于签署请求的消费者/应用程序密钥和消费者/应用程序秘密可以被提取和公开。

例如，如果您是数据的提供者，并且您创建并将消费者密钥提供给想要访问您的用户数据的另一个第三方 Web 应用程序，则密钥和秘密将始终很好地隐藏在第三方 Web 服务器中。没有人应该有权访问它们（某些系统管理员或开发人员除外）。但是这把钥匙并没有向世界公开。

但是，在移动或桌面应用程序的情况下，最终用户必须将此应用程序下载到他们的手机/计算机上。因此，任何黑客都可以下载应用程序并从程序中提取密钥/秘密对。因此，他可以构建一个伪装成原始消费者应用程序的恶意应用程序。

这是迄今为止我所知道的最严重的 OAuth 问题，至少在 1.0a 版本的协议中是这样。问题并没有那么严重，因为最终用户仍然必须批准对恶意应用程序的访问，并且由他们决定它是否具有不同的名称，并且它可能对它想要的 ACCESS 持怀疑态度。但是，当您作为提供商期望拥有移动消费者时，您永远不应该相信他们就是他们所说的那样。

至于上面来自 ATDRE 的示例，我认为您不必担心太多，因为这些文章提出了一些假设场景，并没有具体说明 OAuth 缺陷。如果通过 SSL 完成 OAuth 1.0a 作为协议，它是完全安全的。他们谈论的攻击只是网络黑客的常见例子，与 OAuth 无关。

例如，如果有人窃取了最终用户的 cookie，他当然可以代表用户登录并批准请求……但这不是 OAuth 问题。或者时序示例，它是协议的特定库实现的示例，而不是协议本身......

很抱歉，我无法告诉您有关 OAuth 2.0 的详细信息，因为我还没有实现该版本，但是我可以告诉您，从安全角度来看，该协议的 1.0a 版本是好的......