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

Question

我需要在iOS和Android本机应用程序中集成OAuth2.我一直在研究OAuth2和移动应用程序,并发现了这个文档 - Google API - 使用OAuth 2.0来安装应用程序

上述文档基本上详细介绍了如何在移动应用程序中使用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的安全方法是什么？ - 在浏览器页面中显示授权代码并让用户在应用程序中手动输入它？在这种情况下,浏览器实例是私有的,以便其他应用程序无法监视它并在用户将其键入合法的apication之前获取授权代码本身？

任何帮助表示赞赏

感谢致敬,

Answer 1

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

在大多数移动平台上，您可以“监听”重定向 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 流程中看到的情况，但这是可能的。如果怀疑它会增加任何安全方面的内容。恕我直言，它只会让用户感到沮丧。

这并不意味着有不同的方法来检索和处理授权代码（通过使用本地主机或自定义 URI 方案进行重定向自动捕获代码，或手动传递）