We’re developing a REST API to be consumed by a couple of mobile applications. It’s important that we’re able to trust the identities of these mobile applications. In our current design, each API call is authenticated with an “API Key” parameter and secured with HTTPS.
My concern is that the API Key is embedded within each copy of the mobile app, which means there’s no way we can keep it secret. It will be on thousands of phones, and theoretically any hacker with a binary editor or HTTP Traffic analyzer could extract the API key and then ‘pose as’ one of the applications, sending us requests that we’d have no choice but to trust. Client certificates would appear to have the same risk.
Is there an architecture that solves this problem?
It is being discussed from time to time in different places including StackOverflow. In brief – whatever you put to user’s possession is not yours anymore. You can obfuscate the private key, of course, yet I see at least three ways to bypass your security measures.
The only way to solve a problem could be to employ cryptographic device (smartcard or USB cryptotoken) which keeps private and secret keys and doesn’t let them out, however with handhelds use of such devices is quite complicated (if not impossible) from both technical and usability points of view.
Also you might want to reconsider your approach and let any client software use the service given that they pay for it. And your server will authenticate users and not software. Then the topic of keeping login data secret will be users’ task.