Usar un token

Para que pueda utilizar el Token Seguro de Triton Digital, su aplicación debe hacer lo siguiente:

• Generar un token que contenga los atributos deseados.

• Firmar de manera segura el token, para evitar que se falsifique o reutilice.

• Enviar el token cuando se soliciten medios o anuncios.

• Utilizar el token para el caso de uso deseado (control de acceso, carga de anuncios variable, direccionamiento).

Cómo generar el token

El token es simplemente un mecanismo para proporcionar parámetros adicionales, similares a los parámetros de cadena de consulta de una URL, cuando se recuperan medios (como un podcast o stream en vivo) o se solicitan anuncios. Se crea a partir de una serie de atributos (pares clave-valor). Algunos atributos son obligatorios siempre, pero otros dependen de cada caso de uso. Consulte la sección Carga de JWT (conjunto de reclamaciones) para ver más detalles sobre los atributos disponibles, sus valores y la forma de darles formato para la carga útil de JWT.

En primer lugar, el token tiene un Encabezado Protegido que contiene la información necesaria para identificar el formato y las opciones del token:

• Tipo de token (siempre "JWT").

• Algoritmo de firma (siempre "HS256").

• (proporcionada por Triton).

Además, el token tiene una carga útil que contiene los atributos ya mencionados. Los atributos que incluya dependerán de su caso de uso específico.

Consulte la sección Carga de JWT (conjunto de reclamaciones) para ver los detalles técnicos. Tenga en cuenta que el mecanismo del token de Triton Digital es muy flexible, y si su caso de uso exige atributos adicionales que no forman parte de esta especificación puede comunicarse con nosotros para evaluar el agregado de nuevos atributos compatibles con su caso.

El token también tiene un periodo determinado de validez, para que las URL de los medios no puedan volver a utilizarse después del vencimiento. Esto impide, por ejemplo, que una persona no autorizada use una URL con token que se publicó en un foro, sitio web o agregador sin su permiso. Por lo tanto, se recomienda que el token se genere inmediatamente antes de su uso (por ejemplo, cuando genere los enlaces de su página web a sus medios) y tenga un periodo de validez que sea a la vez breve y práctico. Cuanto mayor sea el tiempo de validez de su token, más tiempo podrá usarlo un tercero no autorizado.

Cómo firmar el token

Una vez generado, el token debe ser firmado por una entidad de confianza para tener validez. Para eso se genera un hash seguro, combinando la carga útil que se debe firmar con una clave secreta (proporcionada por Triton Digital), según la especificación de la JWS (JSON Web Signature, firma web de JSON). Esta firma se anexa al token y será validada por el servidor al recibirla. Los valores de la carga útil solo se considerarán válidos si la firma coincide con la carga y la clave secreta.

Gracias a la firma del token, es imposible alterar su contenido, de modo que los usuarios sin autorización no podrán eludir ningún control de acceso o direccionamiento que haya establecido para sus medios. Como la caducidad del token también es parte de la carga útil firmada, es imposible falsificarla.

Cómo proteger la clave secreta

La pregunta obvia que plantea la sección anterior es "¿cómo mantengo mi clave secreta en secreto?Como en la mayoría de los casos, la respuesta es "depende". Como en cualquier otra situación, dependerá de qué esfuerzo desee destinar a su desarrollo y qué grado de protección busque.

Los criterios que lo guiarán para definir el grado de protección necesario para su clave son:

• Prevención de la falsificación del token;

• Vencimiento del token para evitar la reutilización de las URL de sus medios;

• Protección de la clave secreta contra robos de terceros;

• Identificación de usuarios que reutilicen una URL;

• Facilidad de implementación.

Si bien hay muchas maneras de proteger la clave secreta, las más comunes son:

• Del lado del cliente, en JavaScript, con clave en texto no encriptado;

• Del lado del cliente, en JavaScript, con clave ofuscada (difícil de interpretar);

• Del lado del cliente, en una aplicación nativa (por ejemplo, aplicación móvil o de escritorio);

• Del lado del servidor, con una página web dinámica pública;

• Del lado del servidor, con una página web autenticada;

• Del lado del servidor, usando un servicio autenticado.

Cada alternativa tiene algún término medio, según su caso de uso y el grado de protección que necesite.

En síntesis, todos estos métodos protegerán su token de modo que si un tercero copia las URL de sus medios no pueda reutilizarlas. Como los token tienen vencimiento, siempre es necesario volver a generar regularmente de manera dinámica las URL con un token nuevo.

La manera de implementación más sencilla es, naturalmente, incorporar la clave secreta del lado de su cliente en JavaScript (o la aplicación), pero en este caso para un tercero es insignificante robar la clave (simplemente viendo el código fuente de su página). Igualmente se necesitará generar tokens nuevos, pero aumentará la dificultad para cualquier persona que quiera vincularse con sus medios sin autorización.

El siguiente nivel de protección se consigue ofuscando la clave secreta del lado de su cliente mediante una serie de algoritmos, cada uno de ellos con un grado de protección diferente. Puede variar desde un simple cifrado ROT13 hasta mecanismos muy complejos (como la codificación DRM de los BluRay). Si se ofusca la clave, cualquier tercero que desee copiarla deberá recurrir a un grado de ingeniería inversa de similar complejidad. En cuanto a las aplicaciones nativas (móviles o de escritorio), por su propia naturaleza ya aseguran cierto grado de ofuscación, ya que para obtener la clave es necesario depurar o desensamblar el software. Por último, recuerde que del lado de su cliente la aplicación también necesitará eliminar la ofuscación de la clave para que se pueda usar.

En cuanto a la generación y firma del token del lado del servidor (en una página web pública), de esta manera la clave es imposible de robar. Sin embargo, un tercero podrá igualmente extraer datos de su página web ("rasparla") para obtener las IRL de los medios con tokens. Como dijimos, las URL tienen protección contra la reutilización, y cualquier tercero necesitará volver a "raspar" las URL cada vez que caduque el token.

Por último, la única forma verdaderamente segura de generar URL de medios es utilizar un servicio o página web autenticados del lado del servidor. Esto garantizará que solo los usuarios identificados puedan obtener las URL de los medios con tokens. Además, si incorpora la ID de usuario en el token (con el atributo "sub"), es posible identificar a cualquier usuario que filtre las URL de los medios.

La siguiente tabla resume las ventajas y desventajas de cada alternativa:

Cómo enviar el token

Lea la especificación del servicio en el que se proporcionará el token para obtener detalles sobre la manera de enviarlo. En general se hace por medio de un parámetro de cadena de consulta en la URL del protocolo HTTP del servicio.

Cómo usar el token

Una vez que se haya agregado un token firmado válido a la URL de su servicio, el servidor lo validará para garantizar que no haya caducado y tenga una firma válida (es decir, que se haya usado la clave secreta correcta y que la carga útil del token no haya sido alterada).

Por último, según la configuración del servicio, los contenidos del token (los atributos que proporcionó al generarlo) pueden usarse para las acciones y reglas explicadas anteriormente;

• control de acceso;

• variación de la carga de anuncios;

• direccionamiento de anuncios.

Triton Digital configurará el servicio de manera que se adapte a su caso de uso específico.

Ejemplo de caso de uso: evitar la incorporación (stitching) de anuncios antes del podcast

Este ejemplo de uso describe un caso poco común, es decir, publishers on demand que quieren usar anuncios antes del podcast on demand en vivo en vez de la manera más habitual: incorporar los anuncios a los podcasts. Solo se aplica a publishers que:

• Tengan pleno control de la distribución del podcast a través de su aplicación o reproductor web (es decir, no es apropiado para podcasts que se distribuyen por iTunes o canales similares);

• Restrinjan la distribución del podcast al modo streaming (es decir, no permitan descargar el podcast para escucharlo en otro momento);

• Deseen poder controlar de dónde proviene el anuncio antes del podcast;

• Quieran asegurarse, y tener pruebas, de que se reprodujo el anuncio on demand antes del podcast (y, probablemente, que el oyente lo escuchó).

Use el Token Seguro para controlar la inserción de anuncios antes del podcast de modo que se inserten on demand, cuando se solicite el podcast, en vez de incorporarlos a él. De esta forma, el anuncio es un archivo independiente del podcast y se informa la impresión de inmediato en lugar de la otra opción: tener un único archivo de audio que contenga tanto los anuncios como el contenido en podcast.

Para lograrlo, agregue la clave td-ads a la carga de token seguro del reproductor o la aplicación, utilizando el valor none o nopreroll . (none = no hay costura de anuncio en absoluto; nopreroll = sin costuras antes del rollo, pero los rolls intermedios y posteriores se pueden coser de la manera habitual).

Resultado: no se pueden incorporar los anuncios antes del podcast pero se pueden insertar on demand.

A continuación, configure su podcast como si fuera cualquier otro programa on demand, aplique las campañas de Tap con vuelos de anuncios antes del podcast, etc.