Public API with authorization token — is it possible to protect the demo token?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
9
down vote

favorite
3












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?










share|improve this question





















  • 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
    5 hours ago














up vote
9
down vote

favorite
3












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?










share|improve this question





















  • 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
    5 hours ago












up vote
9
down vote

favorite
3









up vote
9
down vote

favorite
3






3





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?










share|improve this question













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?







authorization api






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 2 days ago









Erlend D.

1554




1554











  • 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
    5 hours ago
















  • 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
    5 hours ago















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
5 hours ago




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
5 hours ago










2 Answers
2






active

oldest

votes

















up vote
25
down vote



accepted










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.






share|improve this answer
















  • 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
    2 days ago






  • 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
    2 days ago










  • @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
    2 days ago










  • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
    – IMSoP
    2 days ago










  • @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
    yesterday

















up vote
11
down vote













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.






share|improve this answer




















    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "162"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f197786%2fpublic-api-with-authorization-token-is-it-possible-to-protect-the-demo-token%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    25
    down vote



    accepted










    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.






    share|improve this answer
















    • 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
      2 days ago






    • 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
      2 days ago










    • @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
      2 days ago










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      2 days ago










    • @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
      yesterday














    up vote
    25
    down vote



    accepted










    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.






    share|improve this answer
















    • 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
      2 days ago






    • 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
      2 days ago










    • @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
      2 days ago










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      2 days ago










    • @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
      yesterday












    up vote
    25
    down vote



    accepted







    up vote
    25
    down vote



    accepted






    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 2 days ago









    GreatSeaSpider

    1,9391013




    1,9391013







    • 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
      2 days ago






    • 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
      2 days ago










    • @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
      2 days ago










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      2 days ago










    • @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
      yesterday












    • 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
      2 days ago






    • 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
      2 days ago










    • @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
      2 days ago










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      2 days ago










    • @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
      yesterday







    1




    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
    2 days ago




    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
    2 days ago




    5




    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
    2 days ago




    @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
    2 days ago












    @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
    2 days ago




    @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
    2 days ago












    @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
    – IMSoP
    2 days ago




    @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
    – IMSoP
    2 days ago












    @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
    yesterday




    @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
    yesterday












    up vote
    11
    down vote













    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.






    share|improve this answer
























      up vote
      11
      down vote













      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.






      share|improve this answer






















        up vote
        11
        down vote










        up vote
        11
        down vote









        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 days ago









        Steffen Ullrich

        111k12191257




        111k12191257



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f197786%2fpublic-api-with-authorization-token-is-it-possible-to-protect-the-demo-token%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?