2

I want to let customers use our API in their mobile applications i.e ones that they develop.

I have never developed for mobile so don't know if having the clients secretAPI key stored in the app is secure. I am assuming they will be able to connect using SSL from the app so transmission will be secure.

From what I am reading online everywhere is suggesting using oAuth. But oAuth requires a sign in from the client's user which is not possible in this case as the clients users wont have an account with our service.

Improve this question
6
  • If they already have API keys and they are developing their own applications other than through TOS how would you stop them doing this?
    – Hector
    Commented Oct 27, 2017 at 9:59
  • I'm not trying to stop clients developing their own applications, the API is limited enough for them not to be able to clone the service. I'm only concerned about the clients API keys being stolen from the code in the mobile app, if that is indeed possible.
    – Guesser
    Commented Oct 27, 2017 at 10:14
  • So you're worried about your clients users? If the token is stored on a users device (either as a file, in the compiled code or even just in memory) that user can in theory extract it. This is the same whether a desktop application on a PC or on a mobile device. If you only want hardware controlled directly by your clients to call the API they would have to forward requests via their own API/server infrastructure.
    – Hector
    Commented Oct 27, 2017 at 10:20
  • So even in the compiled code it could be extracted? That is really my question.
    – Guesser
    Commented Oct 27, 2017 at 10:29
  • I suppose also I am asking if SSL is compiled into the app itself so there is no way of tricking the app to send info that was meant to be encrypted in plain text.
    – Guesser
    Commented Oct 27, 2017 at 10:47

2 Answers 2

Reset to default
6

Anything stored on a user device should be assumed readable by that user. This is regardless of whether its stored in file storage, OS registry, compiled code or even just kept in RAM. It also makes no difference whether the application is a mobile app, desktop application or web app (for data available on the client).

With compiled code you can either inspect the binary directly, use a tool to decompile it or execute the code and take a memory dump then inspect that.

If you want to restrict calls to your API solely to code controlled by your clients then they will have to authenticate their users and forward requests via their own servers.

Improve this answer
4
  • 1
    Ok I see so the client would put an API layer on top of our API? I suppose that is what oAuth is doing in a basic way, just authenticating requests and re-transmitting them if the user is valid to the client and client valid to the service.
    – Guesser
    Commented Oct 27, 2017 at 10:53
  • 1
    Yep - the client would have to build their app to request data from their servers. Their server pulls it from your API. The alternative is to share authentication - with something like oAuth - where clients users can authenticate with your servers to gain access.
    – Hector
    Commented Oct 27, 2017 at 13:16
  • And that second option would require the clients users to be registered to our service right?
    – Guesser
    Commented Oct 27, 2017 at 17:19
  • It depends on the auth technology. You could authenticate users via your clients auth servers. Or they could use a public/private key system which allows you to verify their tokens using their public key.
    – Hector
    Commented Oct 27, 2017 at 17:36
1

It is fair to say that any secret stored in a client app is vulnerable. Secrets stored in manifests or embedded in code are quite easy to extract. Obfuscation and app hardening can make this more difficult. Storing secrets in secure files or keystores is better but still never completely secure. If the secret is valuable enough, it can be stolen.

An overview of mobile API security which starts with API keys and works through OAuth2 is at https://hackernoon.com/mobile-api-security-techniques-682a5da4fe10.

OAuth2 has multiple flows depending on your requirements. The most common flow, authorization code grant, uses both client auth (think API key) and user auth. If you only want client auth, you could use a simpler client credentials flow. AppAuth is an OAuth framework available for iOS and Android. I posted an Android walkthrough of AppAuth at https://hackernoon.com/adding-oauth2-to-mobile-android-and-ios-clients-using-the-appauth-sdk-f8562f90ecff.

For a walkthrough on how secrets can be compromised in an Android app, take a look at https://github.com/approov/shipfast-api-protection. And if you want to see how to remove secrets from your app altogether (requires 3rd party demo library), you can work through https://hackernoon.com/hands-on-mobile-api-security-get-rid-of-client-secrets-a79f111b6844.

Improve this answer

You must log in to answer this question.

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