0

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)

Improve this question
3
  • Will you or won't you distribute your client? Commented Aug 27, 2010 at 2:11
  • I will distribute it to specific Costumers (maybe 20 costumers)... what i don't want is that they develop their own client to consume the webservice... Commented Aug 27, 2010 at 2:14
  • 1
    Why not? Wouldn't it make more sense to build your API and your charging model such that you encourage innovation? Commented Aug 27, 2010 at 3:11

3 Answers 3

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Im pretty sure that everything is breakable, but if there are more rocks in the way, lots will just sit in the side...
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).
1

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

Improve this answer

4 Comments

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...
One form of authentication uses client certificates. Hand out the certificate to only the single application, and permit only that certificate.
Oh, sounds good... any idea to update from server those certificates when expired?
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).
0

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.