Don't want to store the secret Facebook/Twitter API key on mobile devices, design patterns?

Question

I have an issue with letting my secret API key be all over the world on potentially thousands of mobile devices. It could easily be compromised and used for malicious purposes by a hacker.

So what are the options for me? I would guess a private server which has the secret API key and a web service that encapsulates all method calls. So instead of the mobile device having the secret key and does something like:
List<Friends> = service.GetFriends(secretKey);

If my secret API key is compromised and is used for spamming/abuse purposes, I must shut down the use for all my users, leaving my application dead in the sea.

So my idea is that I can use the mobile device unique device ID and do:
List<Friends> = myService.GetFriends(deviceID);

Of course, a malicious hacker could just call my web service with a fake deviceID, but at least I now have control to blacklist deviceID's. It also introduces some potential bandwidth isssue, but that is of a less concern.

A true PKI is probably out of the question, since the targetted device doesn't handle HTTP client certificates in the current version.

Any other good ideas?

Answer 1

You don't want to publish your API key to Facebook or Twitter, even obfuscated within a client.

Your instincts are correct to proxy through a service you control. Limiting access to that service is up to you - how much risk is unauthorized use? Device ID is a pretty good clue to device/user identity, but can be faked.

There are stronger authentication methods you could use (SMS auth, etc) to establish a long-term session or device key, however these are more complex and impose a higher burden on the end user.

TL;DR

Protect your platform API keys. Secure your own API enough to protect your needs.