0

I am currently working on a REST/JSON API that has to provide some services through remote websites. I do not know the end-customers of these websites and they would/should not have an account on the API server. The only accounts existent on the API server would be the accounts identifying the websites. Since this is all RESTful and therefore all communication would be between end-user browser (through javascript/JSON) and my REST API service, how can I make sure that the system won't be abused by 3rd parties interested in increasing the middleman's bill? (where the middleman is the owner of the website reselling my services). What authentication methods would you recommend that would work and would prevent users from just taking the js code from the website and call it 1000000 times just to bankrupt the website owner? I was thinking of using the HTTP_REFERER , and translate that to IP address (to find out which server is hosting the code, and authenticate based on this IP), but I presume the HTTP_REFERER can easily be spoofed. I'm not looking for my customer's end customers to register on the API server, this would defeat the purpose of this API.

Some ideas please?

Thanks, Dan

Dan
  • 43
  • 1
  • 7

1 Answers1

0

This might not be an option for you, but what I've done before in this case is to make a proxy on top of the REST calls. The website calls its own internal service and then that service calls your REST calls. The advantage is that, like you said, no one can hit your REST calls directly or try to spoof calls.

Failing that, you could implement an authentication scheme like HMAC (http://en.wikipedia.org/wiki/Hash-based_message_authentication_code). I've seen a lot of APIs use this.

Using HMAC-SHA1 for API authentication - how to store the client password securely?

Here is what Java code might look like to authenticate: http://support.ooyala.com/developers/documentation/api/signature_java.html

Either way I think you'll have to do some work server side. Otherwise people might be able to reverse engineer the API if everything is purely client side.

Community
  • 1
  • 1
ryan1234
  • 7,237
  • 6
  • 25
  • 36
  • I'm thinking to use something like this: have the remote website first fopen an auth link, where it would provide the end-user IP address via $_SERVER['REMOTE_ADDR'] and server IP via $_SERVER['SERVER_ADDR'], and then the API will generate an expiring token that will be used by the JS code , which token would authorize the customer remote IP for 5 minutes or so. This way (using fopen), i can authenticate that that IP address has reached our API coming from a valid website, and that customer would be able to do whatever he wishes for the next 5 minutes. Any drawbacks that you can see? – Dan Feb 01 '13 at 19:59
  • What happens if the five minutes expires and the user suddenly can't do stuff? Are all your potential clients using PHP? – ryan1234 Feb 01 '13 at 20:03
  • What they use is irrelevant, my API server is using PHP and making use of $_SERVER stuff. I presume I could implement a timer in the js code that would call the auth file (the one that does the fopen) via ajax every 300 seconds , if user is not leaving the current page within that time frame. That would renew the token. – Dan Feb 01 '13 at 20:08
  • Yeah I'm sure you can come up with creative ideas that might work. I don't have any ideas though how to make authentication work really well when it's all purely client side. My idea was to make at least part of the call to your API private (server side). You can obfuscate the javascript that makes the calls, make tokens, look at IPs, etc., but none of that is going to be bulletproof. Maybe just roll it out and log the traffic and see if anyone cares enough to try and spoof calls. – ryan1234 Feb 01 '13 at 20:12
  • well, the first part (where i mentioned fopen) would be private, since thsi would happen from within their php/python/perl/whatever files, and the server would respond back with a token valid for the next 5 minutes which they could use from javascript. – Dan Feb 01 '13 at 20:16
  • Ah ok. Yeah if they're doing some private operation that the front end user can't see ... generating a token ... then I think that's a great idea. – ryan1234 Feb 01 '13 at 20:17