1

When creating a webservice/api that is intended to be used by javascript/flash/mobile clients, what is a good method for making sure that a paying client's credentials are not stolen and reused.

To clarify further, lets say I want to charge $1 for every 10,000 requests against my API. If someone wants to farm my data for free, they would just need to find another client app that already uses my API and construct requests using the credentials of the paying customer.

I don't see any way that I can "hide" what is going on the client, someone will always be able to easily reverse engineer the "auth" scheme. So what are good ways to mitigate abuse?

EDIT

More in depth example of the scenario...

Lets say my data service is bus schedules. The purpose of the services is for developers to write apps consuming the data. There's nothing personal about the data, it is the same for everyone. The intention is for the developer to write javascript/flash/mobile apps directly against the api (I'm aware of cross domain restrictions). But the developer has to pay when users of his app make requests against the bus schedule api. How do I keep another developer going to the original developer's site and just lifting the credentials that are used by his browser to talk to the bus schedule api, and writing his own app using those credentials?

Improve this question

1 Answer 1

Reset to default
2

First of all, just because someone has the code doesn't mean they can bypass your authentication by merely reverse-engineering your code. If you have a private/public encryption in place, having the code doesn't help an attacker much.

On the actual question: The common thing to do seems to be handing out API keys, each of which identifies a paying customer. All requests done through one customer's API key get charged to their account; this way, you hand the responsibility for keeping the API key secret and avoid abuse to the client.

Of course, to avoid eavesdropping and man-in-the-middle attacks, you should serve API requests over HTTPS.

Improve this answer
3
  • 1
    If the code is all javascript running on the browser for instance, HTTPS doesn't protect anything. I can still look at source to get API keys or easily proxy and decrypt ssl traffic.
    – jayrdub
    Commented Jul 20, 2011 at 15:48
  • I added a dumb example that hopefully clarifies the problem a bit
    – jayrdub
    Commented Jul 20, 2011 at 16:12
  • In that case - you can't. At least I don't see how.
    – tdammers
    Commented Jul 20, 2011 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.