Integrate oauth2 with native (iOS/Android) mobile

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 -

When registering the application, you specify that the application is a Installed application. This results in a different value for the redirect_uri parameter.

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.

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 -

The user launches App2
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.
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.
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,

回答1:

From my experience, I've found that there are very little libraries that actually support retrieving the authorization code in a clean way.

On most mobile platform you can "listen" to redirection URLS (being http or some custom scheme)

For example on Android one can easily create an activity to retrieve an access token (based on an authorization code it receives via the redirection 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>

In this case

http://localhost

On mobile platforms like Android this seems like the logical thing to do.

The same can be done on iOS, but the Google OAuth library for iOS uses the page title approach if I remember correctly.

Technically there is no difference between the 2 flows. The only difference is the syntax of the redirection URL, resulting in a different location of the authorization code.

From a security point of view, the authorization code alone is worthless without the OAuth2 client secret.

Having the user enter an authorization code is something that I'm not used to seeing in Oauth2 flows but it is possible. If doubt that it will add anything security-wise. IMHO it will only frustrate the user.

That doesn't mean that there are different ways of retrieving and processing an authorization code (Automatic capturing of the code through redirects with localhost or custom URI schemes, or manual delivery)

回答2:

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.