Handling client side API keys used for deducting credits (money)

Question

Imagine the following scenario:

I've built an API and a web application. A user would sign up through the web app, and receive a unique API key. They may then purchase "credits" for their account, which are simply a 1:1 representation of dollars.

When the user performs an API call, they pass in their API key. This key is used to identify the customer, and subtract credits as necessary.

There is an obvious issue here. If the user performs this call from their own server, and the key is kept private, all is well. However, how would I handle customers who do not have their own server? For example, take a user who has published a simple Android app to the Play Store without a server, and wants to integrate my product. The key would have to be kept client side. A malicious user could then deobfuscate the application, and potentially perform unauthorized API calls spending the credits of the owner of the key.

How can this problem be solved? Is there any way to handle this scenario?

Answer 1

One obvious solution to the problem (in general) is to have a server that manages API keys (so no direct mobile app -> API access allowed). This way, the intermediate server would manage the API key, which could either be the same or different for all callers of the intermediate application. This application could authenticate its callers and potentially decide which API key to use based on the logged on user. This could be pretty error-prone, especially in the long run, if multiple people or teams develop it. Also this is just kicking the problem further along. :)

But say you want a mobile app be able to talk to the API securely. Why would the key have to be hard-coded in the app?

The standard solution to this is that users that downloaded the app get their own API keys on their own devices from the API in runtime. So there is no set key, as you on the API side don't know who your users will be. Once there is a user (from a mobile app or whatever else), you create an API key, and the mobile app can store it the way it wants (which is a whole can of worms btw, long story short, probably the built-in credential store of the mobile platform is best).

Your confusion may come from not having decided what exactly an API key identifies. If it's a user (endusers have their own unique API keys), then it's like described above, they should get their keys individually. If on the other hand the API key identifies your client (the mobile app maker), then they need to have a server, it won't be secure otherwise.