Skip to main content

Allow applications to have multiple application token



  • Bane

    Hey Miguel,

    For features it is generally best to write here: in order to make it possible for anyone to upvote your suggestion (and you can likewise upvote other suggestions / feature requests).

    In regards to the application tokens, when you use the approach from the Danger Zone, you are removing:

    1. the app token,
    2. private key and
    3. encryption toke

    and you are creating a new set of the tokens in their place.

    All video, audio, picture tokens, as well as hosted pages or auth tokens stay as they were.

    • Some hosted pages might need to be updated if you use them and have set the app token manually.

    As you do, the videos are immediately available through this new set of tokens and our player will know to look in these new locations.

    The trouble is for anyone that is saving the URL that includes the application token as then you have to make the call to your DB to update all of those URLs. This can take any amount of time depending on your DB size, resources, etc.

    We generally do not suggest storing the entire URL since some improvements to our system are only available if you use some new endpoint.

    * For example there is a difference between,, and others where some can be interchanged and others are specific to some request and if you capture full URL you might end up on something we currently use only in specific cases.

    • You can get the full URL at any point through the use of our SDK functionality

    Keeping old tokens

    The reason why we are not keeping the old app tokens is because someone to remove these would mean that they have a reason to do so and need a set of fresh tokens. Keeping the old ones as still active might result in leaving the "back door" for someone to still be able to access your application data.

    • Unfortunately sometimes even if you add a warning and arrows in UI it is still possible for someone to be in a hurry and just get a new set and ignore the fact that the previous tokens are still available.
    • tokens do not give access to account, just to single application however with private and encryption tokens as well, they would be able to remove the data within application.

    So looking from that point of view, it is highly unlikely that we would want to change and possibly make things easier to become less secure.

    Possible improvement when switching tokens

    That said, I do see a place for improvement on our current danger zone implementation. One such would be to have something like additional option which would allow for creation of a temporary removal policy which would allow you to get new tokens and have the old ones working for X amount of time (for example next 4 hours).

    That way you can utilize this feature and have no downtime for anyone that is accessing your website from the moment you click to get new set of tokens to the moment the new tokens are added and available within your own system for usage.

    • It might be good to point out that we see the development cycles as something different from the update of application tokens, where application token update does not really require the same QA stages, just someone to update the tokens, then release to public as all config is the same so we have always considered it as a quick update.
    • I would personally always suggest doing this "cleanly" so any dev updates that need to be released are done so outside of scope of application token updates.

    Multiple tokens when using in different projects

    Your advanced use cases suggest the use of tokens in a way where your one app let's say shares the video gallery that is utilized by multiple different applications so you have more control and can exchange the tokens per what it is used for, allowing some tokens to stay as they are.

    For this we would actually need to add additional tokens to our system based on how our application tokens are set currently. At the moment you can only have 1 application token associated with some application, while similar to the above use case this would require a permanent solution that would keep multiple app tokens grouped together.

    This is definitely an interesting thought.

    Hope my comments help you, will pass this to my colleagues and if you create a feedback entry would be happy to add it to our backlog.

  • Miguel Carneiro

    Hi Bane,

    Thanks for the thoughtful reply full of information.

    I have as you suggested created the feedback on

    Wish you an awesome week.

  • Bane

    Awesome, thank you Miguel,

    I saw that it was also upvoted few times :) Will be discussing this with the team to see how we might approach this as this is very complex however will add more details there and then update once we know more.

    Have an awesome week as well :)


Please sign in to leave a comment.