I have a REST API for running some calculations and returning the result, with a very simple token system where only authorized users can use the API.

The user adds their token to the query like this:

    authorization: 'my token',
    moreData: 51351,
    etc: 'etc'

Because the users of this API are usually not programmers, I have made a very simple web page demonstrating the API, with a live demo that can be run directly from the web page, demonstrating how it works and what is returned.

This demonstration has a fake authorization token, which is displayed in the example query. I have made a simple, hidden and partially obfuscated JavaScript function that intercepts this fake token and replaces it with an actual token before sending the request, which will probably trick most users. But a user that actually watches the request from the debug tool in the browser will easily see the actual token that is sent, and can use this token to send their own request.

Of course, I could rate limit the demo token, but then that would mean that users who are experimenting with the live demo could experience temporary lock-outs, which I would like to avoid.

Is there any way of protecting the demo authorization token from an API that needs to be easy to use, and needs a live demo?

  • I would 1) rate limit the demo token, or 2) have people sign up for a unique demo token with a short time limit, or 3) have a demo sandbox simulator, or 4) rate limit the demo token by IP address. – Chloe Nov 18 '18 at 19:07

As Steffen has said you cannot protect the token from users.

I'd just like to add a suggestion for a more general scenario of having a "demo" Api. It sounds like your API doesn't have any stored data and just does calculations on input so this may not be a concern for you, but rather than having the demo token point to your real api, you could point it to a demo / sandbox version with meaningful, but not real data that could:

  1. only have the demo token in it - no other users
  2. be reset automatically on a daily basis
  3. have a small amount of data in it rather than your full set (if you have data)
  4. potentially not return valid results for all calculations as a way of requiring people get a real account from you rather than just using the demo token

This would feel safer to me as your live system would never be touched by anybody with the demo token, and in scenarios where you may have functionality you are selling etc, it allows developers to integrate and confirm they have integrated correctly, but doesn't give away the full set of functionality/data to the demo token.

  • 1
    As a programmer, I would be extremely skeptical of a demo which returned incorrect results without very specific documentation. I would strongly advise against returning the wrong result; rather, I would put limits on the inputs (eg., if the service returned the sum of the values in a list, limit the list to having 5 items). – minnmass Nov 16 '18 at 21:08
  • 5
    @minnmass I see your point, but "not returning valid results" doesn't necessarily mean "returning incorrect results". It might mean returning obvious test strings, like populating name fields with "Mickey Mouse"; or it might mean returning "no results found" for some searches, perhaps with a customised message that they were restricted by the test mode. It really depends on what the API is for; the key point is the demo functionality should not just be free access to the paid functionality. – IMSoP Nov 16 '18 at 23:11
  • @IMSoP: in the general case, I absolutely agree with you; in the case of "a REST API for running some calculations and returning the result", I assumed "running some calculations" means "doing math", and that the only invalid results would be the wrong answer. Hence, limiting the inputs to "trivial" cases. – minnmass Nov 16 '18 at 23:16
  • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree. – IMSoP Nov 16 '18 at 23:17
  • @minnmass even for maths calculations- the response message could be "this demo api rounds all answers to the nearest whole number" or "this demo endpoint only accepts input parameters of less than 100" to limit real world use while allowing potential to be evaluated, and integrations to be reasonably written, along with good documentation of course. As you say - it's all down to the context of what the API is actually doing. – GreatSeaSpider Nov 17 '18 at 12:53

It is not possible to protect the token because as you noticed yourself the user can simply look what kind of request was sent. Since the demo site is under your control you can though change the demo token whenever you want. As long as you only accept valid tokens and you change the token often enough you will limit misuse of the token. And since the page including the token was generated by the server you could also generate a token specific for the users source IP address and maybe a cookie which would further limit any misuse of the token.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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