Is there a safe way to make a monetized API call from a mobile app?

If I'm offering an API service call out to developers and wish to offer for example 500 calls a month for £10, is there a safe way a developer can register and then use their calls from a mobile app they have developed? I'm assuming not because:

  • to monetize the call we need to know which account to bill a call against
  • in order to know which account they have to provide some credentials or have previously obtained an OAuth token
  • if they put the code to pass credentials or get a token in the mobile app, then somebody can reverse engineer and get their credentials
  • once they've got their credentials they can start helping themselves to their 500 calls a month

Not sure if I'm missing something here but I presume the only safe way is for the developer of the app to have their own secure application server which their app talks to, and to make the calls to my API from that. How they secured the connection from their mobile app to their app server would be down to them.

Solved Solved
0 3 269
1 ACCEPTED SOLUTION

You are correct the main challenge is one of securing the authentication process and managing trust relationships, either directly between the mobile app and your API or via a two-step indirect route.

Implementing a secure connection and it typically requires a combination of:

  • using TLS/SSL to encrypt the connection,
  • not storing user credentials in the mobile app or on the mobile device but sometimes that's a convenience feature,
  • using multi-factor auth,
  • session timers to force re-authentication at some interval,
  • considering two-way SSL and VPN technologies as well.

By taking measures to secure the authentication process, making sure some parts of the authentication process are not stored on the mobile device and wrapping it all with encryption you protect the credential data used to generate the token and also the generated token and you minimize or remove the risk of a malicious 3rd party intercepting and helping themselves to the calls.

Take a look at the following references for deeper reading:

eBook: Is Your API Naked?

eBook: Securing the Digital Enterprise

eBook: OAuth - The BIG Picture

Apigee Docs on OAuth

Apigee Docs on API Key Validation

View solution in original post

3 REPLIES 3

You are correct the main challenge is one of securing the authentication process and managing trust relationships, either directly between the mobile app and your API or via a two-step indirect route.

Implementing a secure connection and it typically requires a combination of:

  • using TLS/SSL to encrypt the connection,
  • not storing user credentials in the mobile app or on the mobile device but sometimes that's a convenience feature,
  • using multi-factor auth,
  • session timers to force re-authentication at some interval,
  • considering two-way SSL and VPN technologies as well.

By taking measures to secure the authentication process, making sure some parts of the authentication process are not stored on the mobile device and wrapping it all with encryption you protect the credential data used to generate the token and also the generated token and you minimize or remove the risk of a malicious 3rd party intercepting and helping themselves to the calls.

Take a look at the following references for deeper reading:

eBook: Is Your API Naked?

eBook: Securing the Digital Enterprise

eBook: OAuth - The BIG Picture

Apigee Docs on OAuth

Apigee Docs on API Key Validation

Thanks for the response and the helpful links to the books. I couldn't really find anything specific relating to protecting an API key used for monetisation but I guess the bottom line is (as you've indicated), don't store any API user credentials on the phone.

Not applicable

Dave,

The question you ask is relevant to many use cases - monetization being a very clear example.

As stated it is critically important to protect API Keys, use multi-factor authentication (user and secret), short lived tokens AND have a robust means of monitoring access and resetting keys/secrets when needed.

Ensuring TLS for all transport, not storing secrets on the client, and using reasonably short token TTL values all reduce your exposure.

Hope this helps,

David