Question

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

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

以下是该文件所说的内容 -

注册应用程序时，指定应用程序是已安装的应用程序。这会导致redirect_uri参数的值不同。

在注册期间获取的client_id和client_secret嵌入在应用程序的源代码中。在这种情况下，client_secret显然不被视为秘密。

授权代码可以在浏览器的标题栏中返回到您的应用程序，也可以返回到查询字符串中的http://localhost端口。

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

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

App2 - 恶意应用

我真的不确定上述在本机移动应用程序中集成/使用OAuth2.0端点的技术是不安全还是我遗漏了什么。这是我的问题 -

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

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

用户启动App2
App2将用户重定向到Google OAuth2.0端点，但在请求中，App2包含App1的client_id，并包含App2正在侦听的本地端口号。
当用户被重定向并向Google OAuth2.0端点进行身份验证时，Google会向用户表明“App1（合法应用）要求代表用户访问Google API /数据”这似乎是一种网络钓鱼攻击，因为用户可能会单击是，认为它是要求访问的App1。
然后，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的安全方法是什么？ - 在浏览器页面中显示授权代码并让用户在应用程序中手动输入它？在这种情况下，浏览器实例是私有的，以便其他应用程序无法监视它并在用户将其键入合法的apication之前获取授权代码本身？

感谢任何帮助

谢谢和问候，

Answer 1

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

在大多数移动平台上，您可以“收听”重定向URLS（是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方案重定向自动捕获代码，或手动交付）

Answer 2

不是这个问题的直接答案，而是像我一样来到这里的人并得到过时的答复。最好从这里开始：Google have published他们的OAuth Java库和Scribe已准备好Java。

将oauth2与本机（iOS / Android）移动应用程序集成

2 个答案: