This article is also available in:

Secure content unlocking with a JWS Signature

A reader can gain access to an article in several ways with Poool Access: through a free article, an invisible or automatic unlock, form submission, or newsletter sign-up.

When a reader unlocks content, Poool Access triggers a release event on the client side.
If your architecture relies on server-side content unlocking, you can use this event to request that your server unlock the content and, for example, retrieve the full version of the article from your API.

However, a client-side event can be manually reproduced. A user could potentially simulate a release event and directly call your server to retrieve the content without actually completing the unlock.

A JWS signature helps secure this exchange. Poool signs the release event using a private key, and your server can verify the signature before granting access to your data or the full article content.
This allows you to ensure that the unlock request received by your server was actually issued by Poool before returning the content.

Setting up the JWS signature requires enabling the 'Next' rendering in the Dashboard. To learn more, see our article: Access New Render - What are the changes?

When to implement JWS signing?

Without this option enabled, a script could replicate the unlock event and access your premium content.

Indeed, an event triggered on the client side can be manually reproduced. A user could therefore potentially simulate an unlock and directly call your server to fetch the content without having actually performed the unlocking process.

Another advantage of this feature is that it blocks bad actors who offer extensions or websites that display full articles.

This setup only applies to integrations using Poool Access's custom mode (as opposed to the excerpt or hide modes, which are handled directly by the SDK on the client side). In this mode, the unlocking logic is delegated to your own server, making JWS signature verification relevant.

How does the JWS signature work?

When a release event is triggered, Poool generates a token signed with a private key securely stored in our infrastructure.
The signature is then sent along with the release event. You can forward this signature to your server, which can verify that the token is valid before granting access to the content.

The verification must always be performed server-side. The key used to verify the signature must be stored in your environment variables and must never be exposed on the client side.

How do I enable the JWS signature?

You can enable the feature directly from your application's Settings in the Poool Dashboard.

And activate the toggle:

Once the feature is enabled, a key pair is generated:

The private key remains with Poool and is used to sign release events.
The public key is provided in the Dashboard and must be used on your server to verify the signatures.

No additional SDK configuration is required.

For the full configuration steps and implementation details, see our documentation.

You can enable the feature and define a token expiration time directly from the Poool Dashboard.
The token will only remain valid for the configured duration starting from the click that triggers the release event.
This expiration limits the period during which the token can be used.

What information does the token contain?

The token contains several claims that can be used to verify its origin and intended destination:

iss: the token issuer. This value must be poool.
aud: the Poool application the token is associated with. This value corresponds to the appId used to display the paywall.
jti: a unique identifier generated for each release event.

These claims allow your server to verify that the token was issued by Poool and that it corresponds to your application.

The reader ID and article ID are already available in the context of your page. They therefore do not need to be included in the token and can be correlated with your server-side logic.

How can I prevent token reuse?

Each release event generates a new jti.
You can use this identifier on your server to implement replay protection by storing the jti values that have already been used and rejecting any token whose identifier has already been consumed.
This ensures that the same release event cannot be reused multiple times to unlock content.

What happens if a reader triggers multiple `release` events?

A new token is generated for each release event.
Each token therefore has its own jti, allowing you to distinguish between individual release events and apply your replay protection logic accordingly.