4

We have a mobile app that communicates with our server via a RESTful HTTPS API. We also have an attacker pretending to be our app while attempting to communicate with our web services API.

We assume that our app in the wild can be reverse-engineered to obtain any API keys, shared secrets, private keys, etc.

My question is: Can OAuth2 help to authenticate the app? I'm not asking about authenticating the person. This is not about security of the mobile app. We have to assume the mobile app can be compromised.

In other words, on the server side, how do I distinguish between a legitimate request coming from our app, and an attacker pretending to be the app?

It's been suggested that OAuth2 will help. I don't think this is the case. I don't think OAuth2 is relevant to the problem I'm describing.

I looked at RFC 6749 Implicit Grant flow. To be sure, it does not require a client secret. But its whole point is to log in one place and use that authorization elsewhere. We already do that through our own API. We're not trying to an OpenID Connect sort of thing, just protect our API from attackers.

Can someone confirm that OAuth2 does not help us, from the server side of the equation? Or, if I'm mistaken, please do explain!

Improve this question
2
  • 1
    Your question title is confusing. In a security context, "OATH" usually refers to en.wikipedia.org/wiki/Initiative_For_Open_Authentication. It is not the same thing as OAuth, which is about Authorization, not Authentication the way OATH is.
    – CBHacking
    Sep 14, 2015 at 23:24
  • @CBHacking I am trying to verify that the advice I am getting is missing the issue. I need authentication and I believe OAuth2 is about authorization. I already have authorization covered in the API.
    – Edward Barnard
    Sep 15, 2015 at 0:49

3 Answers 3

Reset to default
1

Do you have consumer key and consumer secret given to the applications? If you do then you can disable access the compromised keys and disable access. API key management can be done without OAuth2. But using OAuth2 would allow you combine key management and use different authentication providers. In order to detect which keys are compromised you would need API analytics or usage reports. OAuth2 does not come with an authentication provider. Securing your API against attackers requires a comprehensive approach. I would suggest to start with API key management and then look at OAuth2 along with authentication provider.

Improve this answer
2
  • 1
    I think that the OP is assuming that the moment that you ship a key in a mobile app it potentially becomes compromised so there's no real way to secure it.
    – Neil Smithline
    Sep 14, 2015 at 19:13
  • Yes to the answer and Yes to Neil's comment. The answer has given me some ideas, though, treating this as a key management issue. Once the mobile app is installed, the user is supposed to log in, which means we have a human authentication. Perhaps we can solve part of the issue based on that aspect. Have to think on that!
    – Edward Barnard
    Sep 14, 2015 at 19:16
1

I agree that OAuth2 is an authorization framework, and authentication must be considered for full security. I would suggest you look into device registration and certificate pinning, to achieve the "trinity" of mobile registration (user ID, device ID and valid certificate). You can add "risk" based step-up multi-factor authentication (OTP, SMS) based on geolocation, or revoke the device cert to block a bad actor.

Improve this answer
1

Some additional thoughts. In a mobile application, I think, we need to consider 3 identities

  1. Users - Typically handled by OAuth token after initial authentication to remove.
  2. Application ID - this is basically the application that is trying to perform operation on user's behalf. It is important to keep this identity separate from user to ensure that you can track, enable disable access to particular application based on various scenario AND it can also help you with billing, tracking. As suggested, API Key management would be best way forward.
  3. Device ID - this is somewhat tied to user but in case you support multiple users on same device, it would be helpful to have this information. In addition to that a lot of behaviour/risk based authentication method would use this information. Device ID should be something that is generated during initial setup and registered as part of initial login/connectivity.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .