views:

65

answers:

2

I'm currently thinking how I could protect my REST API which is used only by my mobile application from being used by other applications? Could a API-Key be a good solution, because just me know the secret API key. Is there a better solution?

+4  A: 

Use HTTP Authentication. REST is all about using the facilities available in HTTP, so the native HTTP auth should be used. With basic authentication you’ll have to use HTTPS though. If you cannot do that use HTTP digest auth or NTLM.

All of them have different strengths and weaknesses, and not every one of them might be supported by your HTTP server and client library.

Sven
So if I use HTTP Basic Authentication in combination with HTTPS, I'm on the safe side? Especially that nobody except me will use my API?
LeonS
Leon if your client and server are not both behind a firewall you have to be concerned about someone packet sniffing your connection. HTTPS encrypts your connection so it can't be sniffed and Basic Authentication provides the API key you want.
Paul Morgan
Even if I provide many users with username and password? So I'm afraid of someone else using my API with another application. Do i can except that with https?
LeonS
A: 

Leon, you keep mentioning "someone else using my API with another application". So, you want to tie your API to be used only by one application? So, you don't want to give access rights to a user, you want to give them instead to an instance of your application running on the user's mobile device.

In essence: You don't trust the user!

Well, in that case you need to make sure your application is closed source, need to code your credentials into your application in such a way that nobody can retrieve them or store the credentials for it in a specially encrypted manner on the device, the decryption key for it being readable only by your application. In a way, you need to implement a form of DRM to prevent people from doing stuff with data on their mobile device. And you need to hope that nobody can reverse engineer it.

If your app becomes popular / interesting enough, count on the fact that people who are very, very good at this sort of thing will look at your application and will break your encryption before you know it. Maybe, if you put the same amount of effort into it as Skype has, maybe then you can ward them off for a while.

But ask yourself: Why bother? Why don't I trust my users? Is it really worth it to jump through hoops like this to prevent some other application from using my API?

Just lead your user through a registration process in which each app instance gets a unique key from the server (or a unique HTTP auth password) and stores that somewhere on the user's mobile device. Then, to access the interesting features in the API, require the presence of this key/password. But don't go through extreme length to obfuscate or encrypt the key when you store it locally, it's not worth it. If you every detect misuse later, you can always revoke the access rights for a particular account on the server anyway.

jbrendel