将oauth2与本机（iOS / Android）移动应用程序集成 [英] Integrate oauth2 with native (iOS/Android) mobile application

问题描述

我需要将OAuth2集成到iOS和Android本机应用程序中。我一直在研究OAuth2和移动应用程序，并发现此文档 - Google API - 使用OAuth 2.0安装应用程序

以上文档主要介绍如何在移动应用程序中使用Goolge OAuth 2.0端点。 b
$ b

以下是文档所述 -

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。 然后，Google OAuth2.0会向App2发出授权代码，然后App2可以发出下一个请求，包括App1的client_id和client_secret，并获取access_token和refresh_token，并继续访问Google的用户数据。
   
   

   
   
   

   ---

   
   
   
   
   
   • redirect_uri也可以是 - ：ietf：wg：oauth：2.0：oob这意味着 -
     
     $ b

     
     

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

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

     以上意味着授权码会在浏览器窗口的标题中返回。

     
     
     

     我的问题是 - App2是否也可以感觉到页面已经加载并捕获了授权代码，然后在App1之前使用它（以及client_id和client_secret）以获取access_token和refresh_token。浏览器实例是否是全球性的，并且任何应用程序都可以监控它，并且上述攻击方案是有效的，或者浏览器实例是某种程度上与应用程序相关的，这样只有App1可以检测/监控这些更改？

     
     
     < hr>
     
     

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

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

     
     
     

     任何帮助表示赞赏

     
     
     

     感谢和问候，
     

     解决方案

     回答这个问题，但对于像我这样来到这里的人，并得到一个过时的答复。最好从这里开始：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 -

     1. When registering the application, you specify that the application is a Installed application. This results in a different value for the redirect_uri parameter.
     2. The client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret.
     3. The authorization code can be returned to your application in the title bar of the browser or to an http://localhost port in the query string.

     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 -

     This value signals to the Google Authorization Server that the authorization code should be returned in the title bar of the browser. This is useful when the client cannot listen on an HTTP port without significant client configuration. Windows applications possess this characteristic.

     When this value is used, your application can sense that the page has loaded and the title of the HTML page contains the authorization code. It is then up to your application to close the browser window if you want to ensure that the user never sees the page that contains the authorization code. The mechanism for doing this varies from platform to platform.

     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）移动应用程序集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！