> ## Knowledge Base Index > Fetch the complete knowledge base index at: https://help.poool.fr/sitemap.xml > Use this file to discover available pages before exploring further. > Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash). # 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? ](https://help.poool.fr/fr/article/rendu-next-sur-access-quels-sont-les-changements-ztje7u/) # 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é](https://help.poool.fr/fr/article/quels-modes-de-blocage-de-contenu-sont-disponibles-dans-poool-access-1cq7on3/#1-la-methode-custom-de-blocage). # 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. ![](https://storage.crisp.chat/users/helpdesk/website/-/5/f/5/0/5f50f52b22503800/capture-decran-2026-09-28-a-14_nnfugf.png) En activant le toggle dédié : ![](https://storage.crisp.chat/users/helpdesk/website/-/5/f/5/0/5f50f52b22503800/capture-decran-2026-09-24-a-15_tgdp1.png) 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](https://www.poool.dev/fr/guides/release-authentication). 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.](https://www.poool.dev/fr/guides/release-authentication)