4

Let's take a look at the basic OAuth workflow:

OAuth scheme

The basic idea is that the Consumer (App) asks the user to grant him access to the Service Provider. The service protects the user by asking him each time the app wants a new access key.

The real problem here is that the service doesn't know much about the consumer. In the case when a mobile app is a consumer, it doesn't even know its URL.

So when the grant access page appears, the service doesn't know who really wants access. So the user gets confused.

What is the solution to this problem?

In the case of a web app, preshared private keys could be used. But it isn't an option for a mobile app (since it is impossible to hide the private key).

Is it really a security threat? I suppose, the user should know from the context which app has requested access. But why then so many websites require a "secret" key? (which isn't really a secret when a mobile app is involved)

Edit

Probably, I wasn't clear enough. Let's try again. Here's an explaining picture:

As you can see, it's the user who should make sure the proper app gets access.

But the message "I don't know who tries to access the service", while being precise, is very confusing.

Is there a technique to identify the app reliably?

|improve this question|||||
  • The problem is that this information would be public. And any other app would be able to send this information pretending to be the original app. – Vanuan May 23 '13 at 8:30
  • I'm more and more convinces that OAuth isn't about authentication. It's about authorization. I mean that client_id (or "secret" key) that identifies the app is public. HTTPS wouldn't secure it anyhow. Because it is reused (i.e. the same for each user). – Vanuan May 23 '13 at 11:34
  • Found the similar question security.stackexchange.com/questions/29747/desktop-api-security – Vanuan May 24 '13 at 9:51
  • Vanuan Well, OAuth is about authorization. :) Authentication isn't actually part of the spec. Or more accurately, is defined in another spec with a pointer that says "go use something similar to that". – Steve May 24 '13 at 17:34
5

So I think that the problem you're describing is, to an extent, solved by adding Client IDs to the authentication request. The application provides an ID to the service provider, and the provider then bounds the token provided to only be valid for that application.

However that doesn't solve the problem of a malicious application which could provide a deliberately forged client ID (if those are used).

The thing is though, in mobile, the application is already trusted, once the user has installed the application he has chosen to trust it. I don't think there's much the service provider can do to protect users from malicious applications, once the user has chosen to install them.

I was watching a video from Eran Hammer (warning NSFW language), where he mentions that where service providers were forcing mobile clients to do web views for user sign-in (to prevent the mobile app from directly accessing the users credentials) and that the mobile app was then overlaying this and grabbing the users credentials, so that they didn't have to bother the user for them in future.

Ultimately I don't think that it's possible to completely protect users from an application once they've decided to trust it by installing it.

|improve this answer|||||
0

I believe the correct way to do this would be to setup a web service to handle login via OAuth and have the application only connect to your web service. From there, the web service could handle the logon the same way as OAuth would normally work (and protect the secret key). You can then use whatever mechanism you want to ensure that the app only connects to your web service for logon.

|improve this answer|||||
  • I think you're not solving this problem. You're just moving it from the level "app -> service" to the level "app -> additional service". – Vanuan May 23 '13 at 8:27
  • @Vanuan - It deals with the immediate problem (as secret keys to communicate with the oauth service providers are protected) but it still requires a means of protecting the app from trying to not use your server. That's a much simpler problem though as you can use SSL and ensure that it connects to the appropriate server (with the appropriate private key). Someone could still hack the application to use another server's certificate, but there is no way to prevent that. – AJ Henderson May 23 '13 at 16:53
  • It seems you didn't read the question carefully enough. I'm not trying to protect the app from being hacked to use another server. It's impossible as you said. I'm trying to protect the service from malicious apps trying to access it. – Vanuan May 24 '13 at 9:29
  • @Vanuan - oh, OAuth doesn't really help with that at all then. The app would be the client and OAuth isn't designed to prove anything about the client. Unfortunately, there isn't really anything you can do that can't fairly easily be copied. You could use a client certificate in the application and use a two way SSL, but someone could hack out that certificate. When someone has complete control of the device, you pretty much have to trust them or not, but there is no way to ensure they behave well unless you do everything server side to disallow any bad things. – AJ Henderson May 24 '13 at 15:29

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.