# Securizando contenido mediante el uso de tokens > En este post compartimos cómo en Transparent Edge securizamos el contenido de los vídeos a través del uso de tokens. Las redes de entrega de contenido desempeñan un papel fundamental en la difusión de vídeo y, más precisamente, en la securización de la propia transmisión. En los últimos años hemos tenido la oportunidad de trabajar mucho este punto mediante el uso de tokens junto a uno de nuestros clientes. En el *post* de hoy os cuento lo que hemos logrado juntos. A diferencia de otros recursos susceptibles de ser suministrados por una [CDN](https://www.transparentedge.eu/blog/que-es-una-cdn/#:~:text=Una%20CDN%20es%20una%20red,nodo%20que%20est%C3%A9%20m%C3%A1s%20cerca.), los vídeos presentan una característica diferenciadora: pesan, pesan mucho. De acuerdo con nuestra monitorización de tráfico en tiempo real, más del 30% del tráfico entregado diariamente por nuestra CDN corresponde a recursos de vídeo a pesar de ser estos solo un 1% del total de peticiones o *requests*.  Sirva este dato simplemente para ilustrar **el peso del que hablo porque influye de forma directa en el ancho de banda y en el coste que supone el tráfico saliente o** ***egress*****.** Dimensionar correctamente estas dos variables es imprescindible para garantizar la calidad del servicio (disponibilidad, tiempo de respuesta, baja latencia, etc.) y la experiencia de usuario. ## Así distribuimos los vídeos en este equipo En [Transparent Edge](https://www.transparentedge.eu/) – y con permiso de [Julio César](https://es.wikipedia.org/wiki/Julio_C%C3%A9sar)– seguimos un enfoque *dívide et ímpera*. Esta aproximación nos invita a dividir un problema complejo en subproblemas de naturaleza equivalente aunque más sencilla y, en consecuencia, abarcables con mayor facilidad. Así pues, **realizamos la transmisión de manera escalonada y progresiva, en pequeños fragmentos más livianos que reciben el nombre de** ***chunks*****.** Pasamos de tener un único recurso, un vídeo de cierta duración, a tener una multitud de pequeños recursos. Para determinar el orden en el que se reproducen estos *chunks*, utilizamos un índice. A estos índices los llamamos manifiestos o *manifests*.  En caso de un vídeo bajo demanda, su manifiesto podría ser el índice de todos los *chunks* que constituyen dicho vídeo, de principio a fin; por el contrario, ante una emisión en directo, este manifiesto se irá refrescando paulatinamente a medida que avanza la emisión.  En términos de políticas de caché, en el primer caso podríamos fijar tiempos relativamente altos de persistencia, por ejemplo, con un ‘max-age‘ de una semana en la cabecera ‘Cache-Control‘. Sin embargo, en el segundo, la política de caché debería ser radicalmente distinta: con una persistencia mínima, de unos pocos segundos, dependiendo de la duración de estos *chunks*. ## Cómo securizar el contenido con *tokens* Podemos imaginar **un** ***token*** **como una especie de firma dinámica que genera la aplicación desde la que el usuario reproduce el contenido y que es verificada por el origen del cliente**. Decimos que es dinámica porque se va actualizando a medida que avanza la reproducción, siendo válida tan sólo durante cierto periodo de tiempo. Para generar un *token* necesitamos ciertas variables: la dirección IP del usuario, el inicio y fin del periodo de validez del *token*, una clave secreta, etc. Las variables concretas dependen en cada caso de las necesidades particulares de cada cliente.  En cualquier caso, estas variables se concatenan de una determinada forma (ej. \[\\]\[\\]\[\\]\[\\]) y se les aplica una función criptográfica o hash. Esta función convertirá la cadena de entrada en una secuencia ininteligible de caracteres, como si [el gato de Schrödinger](https://es.wikipedia.org/wiki/Gato_de_Schr%C3%B6dinger) hubiese podido escapar de su caja y, enfurecido (y zombi, quizá), se hubiera puesto a pegar saltos sobre el teclado del ordenador. El hash resultante, junto con las variables públicas (la dirección IP del usuario y el inicio y fin del periodo de validez del *token*), nos permitirá componer el *token* en sí, que será remitido al origen (*backend*) del cliente, por ejemplo: \-\-\-\.  La petición recibida por el origen recogerá este *token* y extraerá los distintos campos que lo conforman. Tomará las variables y, junto con la clave secreta, repetirá los mismos pasos ejecutados con anterioridad del lado del usuario y comparará los hashes resultantes. **Para que el** ***token*** **recibido sea válido, necesariamente ambos deberán coincidir.** En este punto, nos podemos encontrar distintos escenarios:  - si el origen no recibe ningún *token* o si éste no es válido, el origen podría responder con un *status code 401 (Unauthorized)*;  - si el periodo de validez del *token* aún no ha comenzado, el origen podría devolver un *404 (Not Found); * - si el periodo de validez ha expirado, el origen podría entregar un *410 (Gone).* ## El reto desde el punto de vista de una CDN El uso de *token* afecta irremediablemente a la clave de caché. Cada petición será distinta de todas las demás, aunque hagan referencia al mismo recurso o asset (chunk o *manifest*), desplomando el hit ratio y la eficiencia de la propia caché. Para afrontar este problema podemos seguir dos estrategias: 1. **Implementar una verificación previa o *preflight* *request*** para que al recibir una petición de contenido securizado con *token* se invoque a un servicio externo en el origen (*backend*) del cliente para que nos indique si el *token* es o no válido y, en caso afirmativo, devolver el objeto en caché. Para ello, [Varnish Enterprise](https://www.varnish-software.com/es-es/) nos proporciona herramientas muy interesantes, como es el caso del VMOD http. Esta aproximación es similar a la que seguimos en otros casos de uso y escenarios de naturaleza muy distinta a la que ahora nos ocupa, como puede ser la implementación de muros de pago o *paywalls*. 2. **Delegar el mecanismo de verificación del *token* en la propia CDN.** Para ello es necesario que el cliente comparta con nosotros la forma en la que se genera la firma. Esta es la estrategia que hemos utilizado en el caso que os expongo hoy.  En Transparent Edge proporcionamos una **solución** [***out-of-the-box***](https://docs.transparentedge.eu/security/waf/token) **para proteger contenido mediante *token* y que puede ser integrada sin mayor complicación en la configuración VCL de nuestros clientes**. Aquí, Varnish Enterprise pone a nuestra disposición el VMOD crypto, que nos facilita la vida a la hora de llevar a cabo las operaciones criptográficas de las que hablábamos antes. La principal ventaja que aporta el enfoque elegido es, no ya sólo garantizar una adecuada eficiencia de caché, sino también liberar al origen (*backend*) del cliente de toda la computación que requiere validar uno tras otro los distintos *tokens* remitidos en las peticiones subyacentes. Además, ejecutar estos cálculos en el edge favorece la experiencia de usuario gracias a la red de nodos distribuida estratégicamente por el mundo.  En el caso que abordamos en este *post* hemos trabajado junto a nuestro cliente durante los últimos años, es un honor seguir caminando a su lado y **adaptando nuestras funcionalidades a las necesidades particulares de cada proyecto.** Como recitaba [Antonio Machado](https://es.wikipedia.org/wiki/Antonio_Machado), *«Caminante, son tus huellas el camino y nada más; caminante, no hay camino, se hace camino al andar».* Seguimos caminando. [Alberto Suárez López](https://www.linkedin.com/in/alberto-suarez-lopez/) es administrador de sistemas en Transparent Edge. > > > *Más asturiano que la sidra, Alberto estudió Ingeniería Técnica en Informática de Gestión y un Posgrado en Ingeniería Web en la Universidad de Oviedo. Desde entonces, se ha enfrentado con todos los tipos de infraestructura UNIX posibles y ha doblegado a todos gracias a sus vastos conocimientos que hacen de él un todoterreno ante cualquier problema técnico.* --- Fuente: https://www.transparentedge.eu/blog/securizando-contenido-mediante-el-uso-de-tokens/ Actualizado: 2023-12-27