5

我需要将 OAuth2 集成到 iOS 和 Android 本机应用程序中。我一直在研究 OAuth2 和移动应用程序并找到了这个文档 - Google APIs - Using OAuth 2.0 for Installed Applications

上述文档基本上详细介绍了如何在移动应用程序中使用 Goolge OAuth 2.0 端点。

这是文件所说的 -

  1. 注册应用程序时，您指定该应用程序是已安装的应用程序。这会导致 redirect_uri 参数的值不同。
  2. 注册时获取的 client_id 和 client_secret 嵌入到你的应用程序的源代码中。在这种情况下，client_secret 显然不被视为秘密。
  3. 授权代码可以在浏览器的标题栏中返回到您的应用程序，也可以返回到http://localhost查询字符串中的端口。

假设用户在其智能手机上安装了 2 个应用程序。

App1 - 使用 Google OAuth2.0 端点的合法应用

App2 - 恶意应用

实际上，我不确定的是，上述在原生移动应用程序中集成/使用 OAuth2.0 端点的技术是否不安全，或者我是否遗漏了什么。这是我的问题-

  • redirect_uri 可以是http://localhostURL，并且可以包含任何端口号。端口号不是初始 API 配置的一部分，因此它可以是任何有效的端口号。此外，client_id（无论如何都不应该是秘密）和 client_secret 并不是真正的秘密，因为它们嵌入在移动应用程序源代码中。

使用上述条件，是不是以下可能性 -

  1. 用户启动 App2
  2. App2 将用户重定向到 Google OAuth2.0 端点，但是在请求中，App2 包含 App1 的 client_id 并包含 App2 正在侦听的本地端口号。
  3. 当用户被重定向并通过 Google OAuth2.0 端点进行身份验证时，Google 会向用户指示“App1（合法应用程序）要求代表用户访问 Google API 的/数据”，这似乎是一种网络钓鱼攻击，因为用户可能会单击“是”，认为是 App1 要求访问。
  4. 然后Google OAuth2.0 会向App2 发出一个授权码，然后App2 可以发出下一个请求，包括App1 的client_id 和client_secret 并获得access_token 和refresh_token 并继续从Google 访问用户数据。
  • redirect_uri 也可以是 - urn:ietf:wg:oauth:2.0:oob，这意味着 -

该值向 Google 授权服务器发出信号，授权代码应在浏览器的标题栏中返回。当客户端在没有重要客户端配置的情况下无法侦听 HTTP 端口时，这很有用。Windows 应用程序具有此特性。

使用此值时，您的应用程序可以感知到页面已加载并且 HTML 页面的标题包含授权代码。如果您想确保用户永远不会看到包含授权代码的页面，则由您的应用程序关闭浏览器窗口。执行此操作的机制因平台而异。

上面的意思是授权码是在浏览器窗口的标题中返回的。

我的问题是 - App2 是否也可以感知页面已加载并捕获授权代码，然后使用它（在 App1 之前）与 client_id 和 client_secret 一起获取 access_token 和 refresh_token。浏览器实例是全局的并且任何应用程序都可以监视它并且上述攻击场景是有效的，还是浏览器实例以某种方式特定于应用程序以便只有 App1 可以感知/监视更改？

我的理解正确还是我错过了什么？我是否错过了缓解上述威胁的任何缓解措施？或者鉴于我们在移动操作系统平台上，上述风险是否有效但可以接受？

在移动应用程序中使用 OAuth2.0 的安全方式是什么？- 在浏览器页面中显示授权码并让用户在应用程序中手动输入？在这种情况下，浏览器实例是私有的，以便另一个应用程序无法监控它并在用户将授权码输入合法的apiation之前获取授权码本身？

任何帮助表示赞赏

谢谢并恭祝安康，

4

2 回答 2

0

不是对这个问题的直接回答，而是对于像我一样来到这里并得到过时回复的人。最好从这里开始：Google已经发布了他们的 OAuth Java 库，并且Scribe已经为 Java 做好了准备。

于 2015-03-25T14:45:45.073 回答
0

根据我的经验，我发现实际上支持以干净方式检索授权代码的库很少。

在大多数移动平台上，您可以“监听”重定向 URL（是 http 或一些自定义方案）

例如，在 Android 上，可以轻松地创建一个活动来检索访问令牌（基于它通过重定向 URL 接收到的授权代码。

    <activity android:name=".OAuthAccessTokenActivity" android:launchMode="singleTask">>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="http" android:host="localhost"  />
        </intent-filter>
    </activity>

在这种情况下

http://localhost

在像 Android 这样的移动平台上，这似乎是合乎逻辑的事情。

在 iOS 上也可以这样做，但如果我没记错的话，适用于 iOS 的 Google OAuth 库使用页面标题方法。

从技术上讲，这两种流程之间没有区别。唯一的区别是重定向 URL 的语法，导致授权代码的位置不同。

从安全的角度来看，如果没有 OAuth2 客户端密码，仅授权代码是毫无价值的。

让用户输入授权码是我在 Oauth2 流程中不习惯看到的，但这是可能的。如果怀疑它会增加任何安全性。恕我直言，它只会让用户感到沮丧。

这并不意味着有不同的方式来检索和处理授权代码（通过使用 localhost 或自定义 URI 方案的重定向自动捕获代码，或手动交付）

于 2013-08-07T11:16:24.260 回答