Question

Let’s assume that I have created my REST service smoothly and I am returning json results.

I also implemented API key for my users to communicate for my service.

Then Company A started using my service and I gave them an API key.

Then they created an HttpHandler for bridge (I am not sure what is the term here) in order not to expose API key (I am also not sure it is the right way).

For example, lets assume that my service url is as follows :

http://www.myservice.com/service?apikey={key_comes_here}

Company A is using this service from client side like below :

http://www.companyA.com/services/service1.ashx

Then they start using it on the client side.

Company A protected the api key here. That’s fine.

But there is another problem here. Somebody else can still grab www.companyA.com/services/service1.ashx url and starts using my service.

What is the way of preventing others from doing that?

For the record, I am using WCF Web API in order to create my REST services.

UPDATE :

Company A’s HttpHandler (second link) only looks at the host header in order to see if it is coming from www.companyA.com or not. but in can be faked easily I guess.

UPDATE 2 :

Is there any known way of implementing a Token for the url. For example, lets say that www.companyA.com/services/service1.ashx will carry a querystring parameter representing a TOKEN in order for HttpHandler to check if the request is the right one.

But there are many things here to think about I guess.

Answer 1

You could always require the client to authenticate, using HTTP Basic Auth or some custom scheme. If your client requires the user to login, you can at least restrict the general public from obtaining the www.companyA.com/services/service1.ashx URL, since they will need to login to find out about it.

It gets harder if you are also trying to protect the URL from unintended use by people who legitimately have access to the official client. You could try changing the service password at regular intervals, and updating the client along with it. That way a refresh of the client in-browser would pull the new password, but anyone who built custom code would be out of date. Of course, a really determined user could just write code to rip the password from the client JS programmatically when it changes, but you would at least protect against casual infringers.

With regard to the URL token idea you mentioned in update 2, it could work something like this. Imagine every month, the www.companyA.com/services/service1.ashx URL requires a new token to work, e.g. www.companyA.com/services/service1.ashx?token=January. Once it’s February, ‘January’ will stop working. The server will have to know to only accept current month, and client will have to know to send a token (determined at the time the client web page loads from the server in the browser)

(All pseudo-code since I don’t know C# and which JS framework you will use)

Server-side code:

if (request.urlVars.token == Date.now.month) then
   render "This is the real data: [2,5,3,5,3]"
else
   render "401 Unauthorized"

Client code (dynamic version served by your service)
http://www.companyA.com/client/myajaxcode.js.asp

var dataUrl = 'www.companyA.com/services/service1.ashx?token=' + <%= Date.now.month %>
// below is JS code that does ajax call using dataUrl
...

So now we have service code that will only accept the current month as a token, and client code that when you refresh in the browser gets the latest token (set dynamically as current month). Since this scheme is really predictable and could be hacked, the remaining step is to salted hash the token so no one can guess what it is going to be .

if (request.urlVars.token == mySaltedHashMethod(Date.now.month)) then

and

var dataUrl = 'www.companyA.com/services/service1.ashx?token=' + <%= mySaltedHashMethod(Date.now.month) %>

Which would leave you with a URL like www.companyA.com/services/service1.ashx?token=gy4dc8dgf3f and would change tokens every month.

You would probably want to expire faster than every month as well, which you could do my using epoch hour instead of month.

I’d be interested to see if someone out there has solved this with some kind of encrypted client code!