1

Assuming I developed an Android app using the Google Identify Platform as its ID system. In Google's Identify Platform doc (https://developers.google.com/identity/protocols/OAuth2InstalledApp), it says "Your app must register with the system for the custom URI scheme in order to receive the authorization response".

My question is if a hacker reverse-engineered my APK and figured out my custom URI scheme. He then used that custom URI scheme and released his own Android app with that URI scheme (https://stackoverflow.com/questions/2958701/launch-custom-android-application-from-android-browser). Then Google can be sending OAuth 2.0 authorization response (auth code) to the hacker's Android app.

Isn't that a big security problem?

1

Actually, that is one of the fundamental security problems. If someone knows how your application is supposed to work, then they can mimic it and do evil things like steal tokens.

Given that, there is no direct solution to the problem, but a bunch of related solutions to slightly different problems. These include (but not limited to):

  • Device restrictions to preventing side-loading of apps
  • App validation when submitting to store
  • Store take-down requests

This is the price we (currently) pay for having SSO capabilities within an application. There are other options like requiring custom keys on a per-app-instance basis, but that's impossible to manage, and just makes an attackers job a little bit harder. Conversely, you can push the authentication and token exchange to the device itself within a system-like process, but that just means the evil app needs to do the same thing, which actually might make their job easier.

So what it basically comes down to is whether you're comfortable with the above protections already in place.

|improve this answer|||||
1

This particular security risk has been analyzed in a standard called PKCE, which attempts to mitigate it: https://tools.ietf.org/html/rfc7636. PKCE is an extension to OAuth, and both your server and your app must implement it to use it.

The open source Google sponsored AppAuth library implements PKCE for you. https://github.com/openid/AppAuth-Android

I personally think that using an https:// redirect instead of a custom URI redirect is better. This requires configuration on a server matching the https:// link to make sure your app and only your app can commandeer that redirect -- see https://developer.android.com/training/app-links/index.html for a discussion.

A discussion of some of the issues involved here is buried in this much broader discussion: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03

Notice that this last document suggests using the PKCE mitigation even if you choose the https:// redirect route. I haven't quite figured out what kind of theoretical attack they have in mind. They mention "interapp communication" by which they might mean (I'm guessing) an edge case in which malware has been injected in another installed app signed with your developer key.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.