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











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
    yesterday















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
    yesterday













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 Nov 16 at 7:55









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
    yesterday


















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
















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
yesterday




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
yesterday










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
    Nov 16 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 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 at 23:16










  • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
    – IMSoP
    Nov 16 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
    2 days ago


















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
      Nov 16 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 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 at 23:16










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      Nov 16 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
      2 days ago















    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
      Nov 16 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 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 at 23:16










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      Nov 16 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
      2 days ago













    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 Nov 16 at 9:51









    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
      Nov 16 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 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 at 23:16










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      Nov 16 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
      2 days ago














    • 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 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 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 at 23:16










    • @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
      – IMSoP
      Nov 16 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
      2 days ago








    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
    Nov 16 at 21:08




    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 at 21:08




    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
    Nov 16 at 23:11




    @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 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 at 23:16




    @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 at 23:16












    @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
    – IMSoP
    Nov 16 at 23:17




    @minnmass Yes, if "calculations" is to be taken as literally as that, I absolutely agree.
    – IMSoP
    Nov 16 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
    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
    2 days ago












    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 Nov 16 at 8:02









        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

            Ellipse (mathématiques)

            Quarter-circle Tiles

            Mont Emei