具有隐式授权的 OAuth 应用程序中的客户端模拟答案

【问题标题】：Client impersonation in OAuth application with implicit authorization具有隐式授权的 OAuth 应用程序中的客户端模拟
【发布时间】：2013-10-03 02:29:17
【问题描述】：

来自 OAuth 草案，隐式 section：

在隐式授权流程期间发布访问令牌时，授权服务器不对客户端进行身份验证。

现在，让我们假设：

我有一个 Android 或 iOS 应用程序。
我使用 OAuth 隐式授权来获取对某些资源的访问令牌。这将通过网络视图进行。
用户授权我的应用程序访问某些资源。这意味着：
他在拥有该资源的原始服务中进行了身份验证。
Web 视图将在那里对他进行会话。
有一个恶意的 Android 或 iOS 应用程序试图使用我在应用程序中使用的相同 client_id (client impersonating) 获取访问令牌。他也有同样的redirect_uri，在原生应用中可以是fb://blabla。
据我了解，这个恶意应用程序也可以使用 Web 视图获取原本属于我的 client_id 的访问令牌。发生这种情况是因为用户甚至不会意识到他正在使用的 client_id，这是我的，由于 3.1 和 3.2。
他可以用它做有害的事情，除了我的客户由于过度使用而不得不受到的速率限制（在 FB 和 Twitter 等几个提供商中）。

有什么办法可以防止这种情况发生吗？

【问题讨论】：

【解决方案1】：

link 中的第一条语句：

恶意客户端可以冒充另一个客户端并获取访问权限
到受保护的资源，如果模拟客户端失败，或者是
无法对其客户凭据保密。

我想这是唯一的方法。此外，也许您可以对您的 clientId 应用一些加密，将其加密存储并仅在验证用户身份之前对其进行解密。

【讨论】：

【解决方案2】：

这是一个老问题，但我还是会尝试一下。隐式流本质上是一个不太安全的流，只有当您无法安全地保存客户端 ID 和机密并像在单页应用程序中一样执行代码流（混合流）时，才应使用移动应用程序和/或 Web 应用程序建议服务器端使用代码流来防止此类模仿。

现在换个说法，我不是移动开发人员，所以我不知道“魔术链接”是如何工作的，但我认为如果 2 个应用程序将定义相同的 url（用于重定向 uri），它将失败但这只是我的推理值得检查它......

【讨论】：