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

问题描述

我需要在 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://localhost URL，并且可以包含任何端口号.端口号不是初始 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 的安全方式是什么?- 在浏览器页面中显示授权码并让用户在应用程序中手动输入?在这种情况下，浏览器实例是私有的，因此另一个应用程序无法监控它并在用户将其输入到合法的api中之前获取授权码本身?

感谢任何帮助

谢谢和问候，

解决方案

不是直接回答这个问题，而是针对像我一样来到这里并得到过时答复的人.最好从这里开始:Google 已发布他们的OAuth Java 库和 Scribe 已准备好 Java.

I need to integrate OAuth2 in a iOS and Android native application. I have been researching on OAuth2 and mobile applications and found this documentation - Google APIs - Using OAuth 2.0 for Installed Applications

The above documentation basically details how to consume Goolge OAuth 2.0 endpoint in mobile applications.

Here is what the document says -

Let's say the user has 2 applications installed on their smartphone.

App1 - legitimate app consuming the Google OAuth2.0 endpoint

App2 - malicious app

Really what I am not certain is whether the above technique of integrating/consuming OAuth2.0 endpoint within a native mobile application is insecure or am I missing something. Here are my questions -

---

• The redirect_uri can be a http://localhost URL and can contain any port number. The port number is not part of the initial API configuration and hence it can be any valid port number. Also the client_id (not supposed to be a secret anyway) and client_secret are not really secret since they are embedded in the mobile application source code.

Using the above conditions, isn't the following a possibility -

1. The user launches App2
2. App2 redirects the user to the Google OAuth2.0 endpoint however in the request, App2 includes client_id for App1 and includes the local port number on which App2 is listening.
3. When the user is redirected and authenticates to the Google OAuth2.0 endpoint, Google would indicate to the user that "App1 (Legitimate App) is asking to access Google API's/data on behalf of the user" which seems like a phishing attack since the user might click yes thinking it is App1 that is asking for access.
4. Google OAuth2.0 will then issue an authorization code to App2 and App2 can then make the next request including App1's client_id and client_secret and obtain the access_token and refresh_token and continue to access user data from Google.

---

• The redirect_uri could also be a - urn:ietf:wg:oauth:2.0:oob which means -

The above means that the authorization code is returned in the title of the browser window.

My question is - Can App2 also sense that the page has loaded and capture the authorization code and then use it (before App1) along with the client_id and client_secret to obtain access_token and refresh_token. Is the browser instance global and any app can monitor it and the above attack scenario is valid or is the browser instance somehow application specific so that only App1 can sense/monitor the changes?

---

Is my understanding correct OR Am i missing something? Am I missing any mitigation that mitigate the above threats? OR Are the above risks valid but accepted given that we are on a mobile OS platform?

What is the secure way of using OAuth2.0 in mobile applications? - Display the authorization code in the browser page and have the user manually enter it within the application? And in that case is the browser instance private so that another application cannot monitor it and get hold of the authorization code itself before the user types it into the legitimate apication?

Any help is appreciated

Thanks and Regards,

解决方案

Not a direct answer to this question but for people who come here like I did and get an out of date reply. It's probably best to start here: Google have published their OAuth Java libs and Scribe is Java ready.

这篇关于将 oauth2 与原生 (iOS/Android) 移动应用程序集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！