Best practices of "securing" an API without login/password

alexeypro picture alexeypro · Jul 3, 2012 · Viewed 8.6k times · Source

I have a client app which can be identified with some UID. I have a backend service which the client app needs to call to retrieve some listings. What would be the best practice to secure this backend service? I don't want to protect by login/password (because client should not be required to "login" to retrieve the listings), however, I'd not want anybody easily to call this backend API and retrieve those listings for their own purposes. Think about the client as custom Flash client, or Mobile client, etc. The communication is over HTTP REST. Any ideas?

Thanks

UPDATE: Sorry, forgot to mention -- without using SSL. Basically I am looking for some algorithm/strategy idea here. Thanks for suggestions!

Answer

Robert Levy picture Robert Levy · Jul 3, 2012

The general idea here is that you would use HTTPS with the client configured to sign their requests using a X.509 certificate that the API provider issued to them via some other secure method. The server would have this certificate (or better yet a certificate that the client's certificate is a child of) as well and can verify that the incomming request was signed using it. This is pretty standard for server-to-server communication. It doesn't work if you're building an app for end users to run locally because a bad guy could easily extract this certificate from the client app and defeat the whole scheme

There are lots of technology-specific articles about how to configure this and you haven't specified what stack you're using but here's a generic article just to prove that I'm not making this stuff up :) http://www.ibm.com/developerworks/lotus/library/ls-SSL_client_authentication/