views:

25

answers:

3

I have this webservice at work. For that webservice our department have developed a client to consume the webservice.

What we want to prevent is, that they develop any other client to consume it.

Is there any algorithm, practice that we can improve in our client and webservice communication to validate that the consuming client is our application?

I have an idea, that we can develop an encrypting algorithm about the time (5 seconds of grace) that must match with the calculated on server.

But i want to be sure, there is no best practice for that... or if it still a good idea...

(sorry about my english)

+1  A: 

What you are looking for is known as "authentication".

John Saunders
I can give them an user and a password, and however they will be able to develope their own client app.... i will better asking for some "authorization" algorithm...
Garis Suero
One form of authentication uses client certificates. Hand out the certificate to only the single application, and permit only that certificate.
John Saunders
Oh, sounds good... any idea to update from server those certificates when expired?
Garis Suero
The problem if you use client certificates is that the private key will have to be usable and embedded within the client app, therefore obtainable (perhaps with some effort).
Bruno
@Bruno: not on Windows.
John Saunders
A: 

You need application authentication. For Web based application and services try looking into 2-legged OAuth. In OAuth You give out an id and a secret for every client app which accesses your service and every message is signed for extra security.

Zepplock
+1  A: 

I think part of the point of web services (SOAP or REST based, for example) is to publish an interface that will let your service potentially be used by a variety of client implementations (interoperability is one of the motivations for web services).

If you want to lock your service to be used by your client, the only benefit of having it as a "web service" is probably the tools and libraries with which you've implemented it. You may want to consider whether this was worthwhile (it's possible indeed).

If you distribute your client application, chances are that whatever protection mechanism that may ensure the requests come from that client will have to be embedded with this client. Therefore whatever secret mechanism you embed will probably be only obfuscated to a certain point, but breakable by more advanced users.

Bruno
Im pretty sure that everything is breakable, but if there are more rocks in the way, lots will just sit in the side...
Garis Suero
It really depends on how technically competent your users are. If you ship something with a shared secret, you'll end up with the same problem as the DVD/CSS protection system (break one, break them all). If you ship something with a private key/cert (one per given app), you could revoke a given cert if you suspect foul play. Either way, if someone's willing to disassemble the code, they'll probably find the secret/private key (which you won't be able to lock that well, since you'd want it to be used).
Bruno