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

Question

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 1

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/

Answer 2

Hi I think you could take a look at this article, it uses hmac authentication. http://bitoftech.net/2014/12/15/secure-asp-net-web-api-using-api-key-authentication-hmac-authentication/

Do you remember that hash can be used to guarantee integrity ?for example, if you hash a request,and the server receives the request and the hash diggest, the server will hash the request and compare both requests, server and client. If they match, you can be sure the request has not be modified in the transition. If you have a private value(nobody should know it!), let's say, "hiworld" ( the values are actually guids or random values) and you use that value as parameter for the hash, you would get a special hash value. If you send the request along the hash special value, and the server (who knows the private value) hashes the request using that special value, and both hashs diggest match, the server can be sure that the request was not tampered, and that you were who send it.