Bdtyktl

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?

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.

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.