[jrub]

I think you're describing an HMAC[1] authentication code here.

Certainly signing your requests as actually having come from your application is a legitimate means of security. But there are much lower hanging fruit (in terms of available security measures). Specifically, using SSL to handle API traffic. That should absolutely always be step 0. In instance of this specific post, had the API provider enforced using SSL as their transport protocol we probably wouldn't even be having this discussion.

There's a ton of other security measures/protocols that should be taken and followed, most of which are already talked about in other parts of these comment threads. I just wanted to really point out that what you're describing above sounds an awful lot like an HMAC code.

[1] http://en.wikipedia.org/wiki/Hash-based_message_authenticati...

[JangoSteve]

You're correct; if you see my reply here [1], you'll notice I mentioned it by name.

See #2 in my original response concerning SSL. And notice the difference in length and complexity between #2 and #1; it was written this way intentionally to highlight the complexity of doing security authentication properly, in order to encourage the use of SSL, given that it is both more "full-proof" and simpler.

[1] https://news.ycombinator.com/item?id=7371259

EDIT: Please also see the point @Rizz pointed out, in that you'd still want to use something like OAuth, since HTTPS doesn't solve the issue of an attacker knowing your client's API key by inspecting its distributed code.