Cet article est aussi disponible en :

Sécuriser le déblocage de contenu avec une signature JWS

Un lecteur peut obtenir l'accès à un article de différentes manières avec Poool Access : via un article offert, un déblocage invisible ou automatique, la soumission d'un formulaire ou encore l'inscription à une newsletter.
Lorsqu'un lecteur débloque un contenu via une action Poool, nous déclenchons un événement release côté client.

Si votre architecture repose sur un déblocage côté serveur, vous pouvez utiliser cet événement pour demander à votre serveur de débloquer le contenu et, par exemple, récupérer la version complète de l'article depuis votre API.

La signature JWS permet de sécuriser cet échange. Poool signe l'événement release avec une clé privée, et votre serveur peut vérifier cette signature avant d'autoriser l'accès à vos données ou au contenu complet de l'article.
Vous pouvez ainsi vous assurer que la demande de déblocage reçue par votre serveur provient bien de Poool avant de retourner le contenu.

La mise en place de la signature JWS nécessite d'activer le rendu 'Next' dans le Dashboard. Plus d'info sur ce sujet dans notre article : Rendu 'Next' sur Access, quels sont les changements?

Dans quels cas mettre en place la signature JWS

Sans cette option activée, il est possible qu'un script reproduise l'événement de déverrouillage et accède à votre contenu premium.

En effet, un événement déclenché côté client peut être reproduit manuellement. Un utilisateur pourrait donc potentiellement simuler un release et appeler directement votre serveur pour récupérer le contenu sans avoir réellement effectué le déblocage.

L'avantage de cette fonctionnalité est également de bloquer les acteurs qui proposent des extensions ou sites affichant les articles complets.

Ce fonctionnement concerne uniquement les intégrations utilisant le mode custom de Poool Access (par opposition aux modes excerpt ou hide, gérés directement par le SDK côté client). C'est dans ce mode que la logique de déblocage est déléguée à votre propre serveur, ce qui rend la vérification de signature JWS pertinente. Pour plus de détails sur la configuration des modes, consultez l'article dédié.

Fonctionnement de la signature JWS

Lorsqu'un événement release est déclenché, Poool génère un token signé avec une clé privée conservée dans notre infrastructure.
La signature est ensuite transmise avec l'événement release. Vous pouvez alors transmettre cette signature à votre serveur afin de vérifier que le token est bien valide avant d'autoriser le déblocage du contenu.

La vérification doit impérativement être réalisée côté serveur. La clé permettant de vérifier la signature doit être conservée dans vos variables d'environnement et ne doit pas être exposée côté client.

Comment activer la signature JWS ?

L'activation se fait directement depuis les Réglages de votre application dans le Dashboard Poool.

En activant le toggle dédié :

Une fois la fonctionnalité activée, une paire de clés est générée :

la clé privée reste chez Poool et permet de signer les événements release ;
la clé publique vous est fournie dans le Dashboard et doit être utilisée côté serveur pour vérifier les signatures.

Aucune configuration supplémentaire n'est nécessaire au niveau du SDK.

Pour retrouver les étapes de configuration et l'implémentation complète, consultez notre documentation.

Vous pouvez activer et définir une durée d'expiration du token depuis le Dashboard Poool.
Le token sera alors valide uniquement pendant la durée définie à partir du clic déclenchant l'événement release.
Cette expiration permet de limiter la période pendant laquelle le token peut être utilisé.

Quelles informations contient le token ?

Le token contient plusieurs informations permettant de vérifier son origine et sa destination :

iss : l'émetteur du token. Cette valeur doit être poool.
aud : l'application Poool concernée. Cette valeur correspond à l'appId utilisé pour afficher le paywall.
jti : un identifiant unique généré pour chaque événement release.

Ces informations permettent à votre serveur de s'assurer que le token a bien été émis par Poool et qu'il correspond à votre application.

L'identifiant du lecteur et l'identifiant de l'article sont déjà disponibles dans le contexte de votre page. Ils n'ont donc pas besoin d'être ajoutés au token pour être corrélés à votre logique côté serveur.

Comment éviter la réutilisation d'un token ?

Chaque événement release génère un nouveau jti.
Vous pouvez utiliser cet identifiant côté serveur pour mettre en place une protection contre les attaques par rejeu : il vous suffit de conserver les jti déjà utilisés et de refuser un token dont l'identifiant a déjà été consommé.
Ainsi, un même événement release ne peut pas être réutilisé plusieurs fois pour débloquer du contenu.

Que se passe-t-il lorsqu'un lecteur déclenche plusieurs fois un release ?

Un nouveau token est généré à chaque événement release.
Chaque token possède donc son propre jti, ce qui permet de distinguer les différents événements et d'appliquer votre logique de protection contre le rejeu.

Pour aller plus loin

Pour retrouver les exemples de code et le détail de l'implémentation côté client et côté serveur, consultez notre documentation technique sur la sécurisation du déblocage de contenu avec une signature JWS.

Mis à jour le : 05/10/2026

Cet article a-t-il répondu à vos questions ?

Merci !