Question

I’m trying to figure out the best way to secure an API. I only allow SSL and I’m using OAuth2 for authentication, but that doesn’t seem like enough.

The major concern I have is that anyone could inspect the requests being made by a legitimate client to the API and steal the OAuth client_id. At that point they would be able to construct any request they want to impersonate the legitimate client.

Is there any way to prevent this? I’ve seen people use a HMAC hash of the parameters using a secret key known only to the client and server but I see 2 problems with that.

1. It’s very difficult (impossible?) to prevent a malicious user from decompiling your client and figuring out the secret key.
2. Some parameters seem odd to make an HMAC hash of. For example if a parameter was bytes of a file, do you include the whole thing in your HMAC hash?

Answer 1

You can deploy mutually-authenticated SSL between your legitimate clients and your API. Generate a self-signed SSL client certificate and store that within your client. Configure your server to require client-side authentication and only accept the certificate(s) you’ve deployed to your clients. If someone/something attempting to connect does not have that client certificate, it will be unable to establish an SSL session and the connection will not be made. Assuming you control the legitimate clients and the servers, you don’t need a CA-issued certificate here; just use self-signed certificates since you control both the client-side and server-side certificate trust.

Now, you do call out that it’s really hard to prevent someone from reverse engineering your client and recovering your credential (the private key belonging to the client certificate, in this case). And you’re right. You’ll normally store that key (and the certificate) in a keystore of sometype (a KeyStore if you’re using Android) and that keystore will be encrypted. That encryption is based on a password, so you’ll either need to (1) store that password in your client somewhere, or (2) ask the user for the password when they start your client app. What you need to do depends on your usecase. If (2) is acceptable, then you’ve protected your credential against reverse engineering since it will be encrypted and the password will not be stored anywhere (but the user will need to type it in everytime). If you do (1), then someone will be able to reverse engineer your client, get the password, get the keystore, decrypt the private key and certificate, and create another client that will be able to connect to the server.

There is nothing you can do to prevent this; you can make reverse engineering your code harder (by obfuscation, etc) but you cannot make it impossible. You need to determine what the risk you are trying to mitigate with these approaches is and how much work is worth doing to mitigate it.