As AndyC said "That still boils down to "How can I identify the calling program?" and the answer is still "You can't. Ever"
http://blogs.msdn.com/b/oldnewthing/archive/2006/08/18/705957.aspx"

 

1) Makes a good point that there is user security only, not application security.

2) Assume your network api is a public interface, because it is.

3) Assume other client software can and will call your api.  For that matter, in general you want other client sw and/or extentions to call your public api.  The server side is the barrier and should expect all calls are bad. 

4) I don't need to decompile your client library or figure out your secret hiding places.  You have already published a beautiful api for me that I can reference and call with my own program.   Your code does all the work for me.   Interactive/prompted userid and passwords is only way.  I must know a proper id and password to gain entry on any call is the goal.  Once I prove that to you, then I should be able to do anything your public api allows without compromising anything on server side - now I am on the hook because you know it is me or I gave my password to someone or they guessed it (so then turn it off and investigate).  If I am allowed to do bad things with my id, then server security needs more attention.