Utiliser un jeton

Pour utiliser le jeton d'authentification Triton Digital, votre application doit faire ce qui suit :

• Générer un jeton, contenant les attributs souhaités.

• Signer sûrement le jeton pour prévenir la falsification et la réutilisation.

• Envoyer le jeton à la demande des médias ou des publicités.

• Utiliser le jeton pour le cas d'utilisation souhaité (contrôle d'accès, chargement d'une publicité variable, le ciblage).

Génération du jeton

Le jeton est simplement un mécanisme permettant de fournir des paramètres supplémentaires, similaires aux paramètres des chaines de requêtes sur une URL lors de la récupération des médias (par exemple un flux en direct, un podcast) ou à la demande de publicités. Il est conçu à partir d'une série d'attributs (par exemple les paires de valeurs clés). Certains attributs sont toujours nécessaires mais d'autres dépendent de votre cas d'utilisation. Voir la section Charge utile JWT (série de réclamations) pour plus de détails sur les attributs disponibles, leurs valeurs et comment les formater en charge utile JWT.

D'abord, le jeton à un intitulé protégé, contenant les informations nécessaires pour identifier les options et le format du jeton :

• Type de jeton (toujours « JWT »).

• Algorithme de signature (toujours « HS256 »).

• code d'identification (fourni par Triton).

Ensuite, le jeton a une charge utile contenant les attributs mentionnés précédemment. Les attributs que vous incluez dans le jeton dépendent de votre cas d'utilisation prévu.

Voir la section Charge utile JWT (série de réclamations) pour plus de détails techniques. Notez que le mécanisme de jeton Triton Digital est très flexible et si votre cas d'utilisation nécessite d'autres attributs qui ne sont pas inclus dans cette spécification, contactez-nous pour discuter de l'ajout de nouveaux attributs pour prendre en charge votre cas d'utilisation.

Un jeton a également une période de validité, de sorte que l'URL d'un média ne puisse pas être réutilisée après l'expiration de la période. Cela empêche, par exemple, les personnes non autorisées d'utiliser une URL équipée d'un jeton qui a été publiée dans un forum, un site Web ou un agrégateur sans votre permission. Il est donc recommandé que le jeton soit généré juste avant son utilisation (par exemple lors de la génération du lien de votre page Web vers votre média) et ait une période de validité aussi courte que possible. Plus la période de validité de votre jeton est longue, plus longtemps une partie non autorisée peut l'utiliser.

Signature du jeton

Une fois le jeton généré, il doit être signé par une entité de confiance pour devenir un jeton valide. Cela peut se faire en générant un hachage sûr, combinant la charge utile à signer et une clé secrète (émise par Triton Digital) selon la spécification JWS (JSON Web Signature). Cette signature est ensuite ajoutée au jeton et sera validée par le serveur lors de la réception. Les valeurs dans la charge utile seront considérées valides seulement si la signature correspond à la charge utile et la clé secrète.

En signant le jeton, il est impossible de falsifier le contenu du jeton, les utilisateurs non autorisés ne peuvent donc pas contourner le contrôle d'accès ou le ciblage que vous avez paramétré pour votre média. Comme l'expiration du jeton fait également partie de la charge utile signée, il est impossible de falsifier l'expiration.

Protection de la clé secrète

La question évidente que la section précédente pose est « comment garder secrète ma clé secrète ?Comme dans la plupart des cas, la réponse est « cela dépend ». Comme pour tout le reste, protéger une clé secrète est toujours un équilibre entre l'effort de développement et le niveau de protection que vous accordez à cette clé.

Les critères qui vous aideront à déterminer le niveau de protection nécessaire pour votre clé secrète sont :

• La prévention de la falsification du jeton :

• L'expiration du jeton pour prévenir la réutilisation des URL de vos médias ;

• La protection de la clé secrète d'un vol de tiers ;

• L'identification des utilisateurs qui réutilisent une URL ;

• La facilité d'implémentation.

Il existe de nombreuses façons d'implémenter la protection de la clé secrète, mais les plus courantes sont les suivantes :

• Côté client, dans JavaScript, avec une clé au clair ;

• Côté client, dans JavaScript, avec une clé masquée ;

• Côté client, dans une application native (par exemple une application mobile ou bureau) ;

• Côté serveur, avec une page Web dynamique publique ;

• Côté serveur, avec une page Web authentifiée ;

• Côté serveur, en utilisant un service authentifié.

Il y a des compromis à faire pour chaque alternative, en fonction de votre cas d'utilisation et du niveau de protection dont vous avez besoin.

En bref, toutes ces méthodes protégeront votre jeton contre la réutilisation de vos URL de médias lorsqu'un tiers les copie. En raison de l'expiration des jetons, il est toujours nécessaire de régénérer dynamiquement et régulièrement les URL avec un nouveau jeton.

L'implémentation la plus simple consiste évidemment à intégrer la clé secrète dans votre JavaScript (ou application) côté client, mais il est alors très facile pour un tiers de voler la clé (simplement en consultant le code source de votre page). Ils devront toujours générer de nouveaux jetons, mais cela crée un niveau de difficulté supplémentaire pour toute personne souhaitant établir un lien direct avec vos médias sans autorisation.

Le niveau de protection suivant consiste à masquer la clé secrète dans votre code côté client à l'aide de divers algorithmes, chacun offrant un niveau de protection différent. Cela peut aller d'un simple ROT13 à des systèmes très complexes (par exemple, un DRM de type BluRay). Le masquage de la clé nécessite donc un niveau correspondant de rétro-ingénierie par des tiers souhaitant copier votre clé. Quant aux applications natives (mobiles ou de bureau), elles procurent un certain niveau de masquage par leur nature même, car elles nécessitent le désassemblage ou le débogage de votre logiciel pour obtenir la clé. Enfin, rappelez-vous que l'application côté client aura elle-même besoin de révéler la clé avant son utilisation.

Quant à la génération et la signature du jeton côté serveur (sur une page Web publique), cela rend la clé impossible à voler. Cependant, un tiers peut toujours racler votre page Web pour obtenir les URL des médias avec jetons. Là encore, les URL sont protégées contre la réutilisation, et les tiers devront racler encore une fois les URL à chaque fois que le jeton expirera.

Enfin, le seul moyen de générer des URL de médias de manière vraiment sûre est de le faire derrière un service ou une page Web authentifiés côté serveur. Cela garantit que seuls les utilisateurs identifiés peuvent obtenir les URL des médias avec jetons. Aussi, si vous intégrez l'ID utilisateur dans le jeton (avec l'attribut « sous »), il est possible d'identifier n'importe quel utilisateur qui fuit les URL des médias.

Le tableau suivant offre une vue d'ensemble des avantages et des inconvénients de ces alternatives :

Envoi du jeton

Référez-vous à la spécification du service où le jeton sera fourni pour plus de détails sur l'envoi du jeton. Cela se fait généralement via un paramètre de chaîne de requêtes sur l'URL HTTP du service.

Utilisation du jeton

Une fois qu'un jeton signé valide a été ajouté à votre URL de service, le serveur validera le jeton pour s'assurer qu'il n'est pas expiré et a une signature valide (ce qui signifie que la bonne clé secrète a été utilisée et que la charge utile du jeton n'a pas été falsifiée).

Enfin, en fonction de la configuration du service, le contenu du jeton (les attributs que vous avez fournis lors de la génération du jeton) peut être utilisé pour exécuter les actions et les règles expliquées précédemment :

• contrôle d'accès ;

• variation de la charge de publicité ;

• ciblage de publicité.

Triton Digital configurera le service pour prendre en charge votre cas d'utilisation spécifique.

Exemple de cas d'utilisation : Prévenir le collage des publicités avant la diffusion aux podcasts

Cet exemple décrit un cas inhabituel pour les éditeurs à la demande qui souhaitent utiliser des publicités avant la diffusion en direct et à la demande avec des podcasts au lieu du cas typique où les publicités avant la diffusion sont collées aux podcasts. Cela s'applique pour les éditeurs qui :

• ont le contrôle total de la distribution des podcasts via leur application ou leur lecteur Web (c'est-à-dire que cela ne convient pas aux podcasts qui sont distribués via iTunes ou des canaux similaires) ;

• Limitent la distribution des podcasts au mode streaming (c'est-à-dire qu'ils ne peuvent pas être téléchargés pour une écoute ultérieure) ;

• Souhaitent avoir le contrôle sur la provenance des publicités avant la diffusion ;

• Souhaitent s'assurer, et obtenir une preuve, que la publicité avant la diffusion à la demande est lue (et probablement écoutée par l'auditeur).

Utilisez le jeton d'authentification pour contrôler l'insertion des publicités avant la diffusion afin qu'elles soient insérées à la demande lorsque le podcast est demandé, au lieu d'être collée au podcast. Ainsi, la publicité est considérée comme un fichier distinct du podcast et l'impression est rapportée immédiatement, au lieu d'avoir un seul fichier audio qui contient à la fois le contenu des publicités et des podcasts.

Pour ce faire, ajoutez la clé de td-ads  ; à la charge utile du jeton de sécurité du lecteur ou de l’application, en utilisant la valeur none ou nopreroll . (none = pas d’insertion de publicité du tout ; nopreroll = pas d’insertion avant la diffusion, mais les éléments en cours de diffusion et après la diffusion peuvent être intercalés comme d’habitude.)

Résultat : les publicités avant la diffusion ne sont pas collées, mais peuvent être insérées à la demande.

Ensuite, configurez votre podcast comme n'importe quel autre programme à la demande ; appliquez les campagnes Tap avec des vagues de publicités avant la diffusion, etc.