{"id":19949,"date":"2023-09-21T16:40:15","date_gmt":"2023-09-21T14:40:15","guid":{"rendered":"https:\/\/www.transparentedge.eu\/en\/blog\/"},"modified":"2025-07-08T15:19:28","modified_gmt":"2025-07-08T13:19:28","slug":"tokens-to-secure-content","status":"publish","type":"post","link":"https:\/\/www.transparentedge.eu\/en\/blog\/tokens-to-secure-content\/","title":{"rendered":"Securing content through the use of tokens"},"content":{"rendered":"\n

Content delivery networks play a fundamental role in video broadcasting and, more precisely, in securing the transmission itself. In recent years we have had the opportunity to work a lot on this point through the use of tokens together with one of our clients. In today’s post I tell you what we have accomplished together.<\/p>\n\n\n\n

Unlike other resources that can be delivered by a CDN<\/a>, videos have a differentiating characteristic: they are heavy, very heavy. According to our real-time traffic monitoring, more than 30% of the traffic delivered daily by our CDN corresponds to video resources, despite being only 1% of the total requests.<\/p>\n\n\n\n

This information simply serves to illustrate the weight I am talking about because it directly influences bandwidth and the cost of outgoing or egress traffic<\/strong>. Correctly sizing these two variables is essential to guarantee the quality of the service (availability, response time, low latency, etc.) and the user experience.<\/p>\n\n\n\n

This is how we distribute the videos<\/h3>\n\n\n\n

At Transparent Edge \u2013 and with permission from Julius Caesar<\/a> \u2013 we follow a d\u00edvide et impera<\/em> approach. This approach invites us to divide a complex problem into subproblems of an equivalent but simpler nature and, consequently, more easily manageable. Thus, we carry out the transmission in a staggered and progressive manner, in smaller, lighter fragments called chunks<\/em><\/strong>.<\/p>\n\n\n\n

We went from having a single resource, a video of a certain length, to having a multitude of small resources. To determine the order in which these chunks are played, we use an index. We call these indexes manifests<\/em>.<\/p>\n\n\n\n

In the case of a video on demand, your manifest could be the index of all the chunks <\/em>that make up that video, from start to finish; conversely, in the case of a live broadcast, this manifest will be gradually refreshed as the broadcast progresses.<\/p>\n\n\n\n

In terms of cache policies, in the first case we could set relatively high persistence times, for example with a \u2018max-age<\/code>\u2018 of one week in the \u2018Cache-Control<\/code>\u2018 header. However, in the second case, the cache policy should be radically different: with a minimum persistence of a few seconds, depending on the duration of these chunks<\/em>.<\/p>\n\n\n\n

How to secure content using tokens<\/h3>\n\n\n\n

We can imagine a token as a kind of dynamic signature generated by the application from which the user plays the content and verified by the client’s origin. We say it is dynamic because it is updated as the playback progresses, being valid only for a certain period of time.<\/p>\n\n\n\n

To generate a token we need certain variables: the user’s IP address, the start and end of the token’s validity period, a secret key, etc. The specific variables depend in each case on the particular needs of each client.<\/p>\n\n\n\n

In any case, these variables are concatenated in a certain way (e.g. [<IP address>][<valid from>][<valid until>][<secret key>]<\/code>) and a cryptographic or hash function is applied to them. This function will convert the input string into an unintelligible sequence of characters, as if Schr\u00f6dinger’s cat<\/a> had escaped from its box and, enraged (and perhaps zombie-like), had started jumping around on the computer keyboard.<\/p>\n\n\n\n

The resulting hash, together with the public variables (the user’s IP address and the start and end of the token’s validity period), will allow us to compose the token itself, which will be sent to the client’s backend, for example: <IP address>-<hash>-<valid from>-<valid until><\/code>.<\/p>\n\n\n\n

The request received by the origin will collect this token and extract the different fields that make it up. It will take the variables and, together with the secret key, it will repeat the same steps previously executed on the user’s side and compare the resulting hashes. For the token received to be valid, both must necessarily match.<\/p>\n\n\n\n

At this point, we can find different scenarios:<\/p>\n\n\n\n