As soon as you release the application, it might be reverse engineered. This means that there is nothing you can do to be 100% protected if the same application (same binaries, same settings) is distributed to all of your users.
If you can customize the application for every user, then you have a chance to maybe not forbid some other application to use your API, but at least limit this application by number of requests it can do to the API.
Imagine the following schema:
- Client connects and sends its unique identifier (one identifier by user).
- Server replies by sending a challenge encrypted with a public key. This public key is associated with the unique identifier previously sent.
- Client solves the challenge by decrypting the data using a private key and sends the decrypted secret in plain back to the server.
- Server verifies that the submitted secret corresponds to the one originally generated.
The developer who will hack your application and successfully obtain the private key would be able to use your API from his own application, but he will be identifier as himself for your server.
If the same user can do 10 000 requests to your API per day and in average, an active user makes 2 000 requests per day, it means that this developer would be able to use his application himself and maybe give it to his friends, but he wouldn't be able to, say, sell it to thousands of people, just because it will work only for a few minutes in the morning.
While this helps, it's not 100% proof neither. What if the hacker finds a way to extract the private key from your app when his own app is installed on the device?
Side note which doesn't answer your question, but still might be useful: don't think about an API as a tool for your primary product (mobile application). Think about it as a first class product itself, a product which may be paid. The same model is used for years by Amazon and Google, it starts to be actively used by Microsoft with Azure, etc.
As soon as you consider the API not as a secondary tool reduced to slavery for your shiny new mobile apps, but the actual product, at the same level as any application the user actually sees, you start thinking less about how to protect the API against the usage by other apps, and more about the monetization of the API itself. Such API can be used by your apps which are its customers, or any other apps, freely developed by anyone. This has several benefits:
Making an API so that it would be used only by your applications is difficult and expensive. This time and money can be used for something more useful.
Opening your API to the public can have a great benefit for both you and the world. Imagine you're a great architect and a great developer, so you've created an astonishingly great API, but your visual designer skills suck and you really don't understand anything about interaction design, etc. If you hide your API, the only thing people will know is that you've created a mobile application which is unusable and ugly. If your API is public, other developers will be attracted by its quality and write great applications for it, bringing you lots of money.
You never imagine how other people may use your APIs. This is what happened with Kinect. Originally, Microsoft created Kinect for games. When Microsoft opened the API to the public, they never imagined it would be used a few years later by scientific applications, health sector, etc. It's similar for web APIs: more developers are using it, more widespread the ideas would be.
Best Answer
I really like the first approach in general.
One thing I don't see mentioned about the first that you should keep in mind, the timestamp used to hash the token needs to have a TTL expiry that's exceedingly short (like 1 second) so you verify the message wasn't sent with the same timestamp and token from a message 12 hours earlier; obviously it would calculate as legit but is not in this case.
If these are the only two options you're considering though I'd just like to make sure you've looked at other approaches too, as there are many. More than I'm going to list in fact. These are some common auth approaches which are worth studying just to see if they might fit your purpose better, and if nothing else understanding them may give you some ideas to help tighten up whichever approach you do go with.
Do note, I am not a security expert.
OAuth/Federated
In this approach you have a 3rd party guarantor where the consuming code requests the token/cert/what have you from them and passes that to you, at this point all you need to do is ask the 3rd party if the key you were given is legit.
Pro:
Con:
Asynchronous Certificates
Here you would have your clients encrypt their communications with a public cert you have shared with them when they created a user. On your side you would decrypt using the private key associated with there user. Generally you would initiate the communication with a challenge-response to show they can encrypt/decrypt as you expect identifying them as who they claim to be. Though "synchronous" approaches are possible which don't use the challenge-response, they have slightly less security and some time synchronization issues which can make them trickier.
from Novell (yeah I know, novell? really?)
Pro:
Con:
NTLM
Don't laugh, if this is a smaller or internal only service and you're in a windows environment, there is nothing wrong with using standard NTLM authentication to guarantee access. Especially if you're working with IIS this is hands down the simplest approach. Easy to maintain and configure as well in a web.config.
Pro:
Con:
Nonces
When working with nonces in your authentication approach, you supply a method to get a nonce on the service. This method returns a unique arbitrary string or piece of data ("a nonce") on each request. Every request to other methods now require a nonce to be retrieved, and used in the crypto algorithm for the request. The value here is that the server keeps track of the nonces used, and never allows reuse of a nonce, this completely prevents replay attacks because once a request with one nonce is made, a request with that nonce can never be made again. As nonces are requested they're added to a list of available nonces, as they're used they're moved from the available list to the used list. When generating a nonce you ensure what you generate is not on the used list and the available list will never again have one of the old ones and therefore no repeats can be made.
Pro:
Con: