Because JWTs can be signed (for example, using public/private key pairs), you can be sure that when Maropost sends a payload in a webhook callback, we are who we say we are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.
By default, Maropost doesn’t enforce the use of JWT. However, you have the option of using the JWT authentication in the following places:
Generating and Using JWT
Steps to generate the JWT:
-
Click your user name on the top-right corner of the application, and then from the drop-down menu, select Settings.
-
On the Settings page, in the Connections section, click JSON Web Token.
-
Click Generate JWT.
The JWT is generated and displayed on the page.
📋 Note: You can regenerate the JWT by clicking the Re-generate JWT button. This will generate a new public key that will be used in all subsequent webhook calls.
Using the JWT:
Once generated, the JWT is displayed on the JSON Web Token page. Copy the token exactly as it is displayed on the page and paste it into your system code that validates Maropost's calls to your API endpoint.
Learn More…
What is JSON Web Token (JWT)?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. The information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
Authenticating JWT
Maropost uses the public/private key pair to generate the JWT using the RS256 encryption algorithm. The JWT is included in the header of the HTTPS POST call that Maropost makes to your API endpoint.
Decode the JWT using the public key to verify the signature.
Maropost includes the following claims in the JWT:
-
jti – A unique identifier generated each time a webhook call is made to your API endpoint.
-
exp – The expiration time on or after which the JWT must not be accepted for processing.
-
nbf – The time before which the JWT must not be accepted for processing.
-
iss – The issuer of the JWT which in this case will always be "Maropost Inc."
-
iat – The time at which the JWT is issued. This claim can be used to determine the age of the JWT.
-
sub – The subject of this JWT. In the previous example, "journeys" indicates that the HTTPS POST payload was triggered by a Journey.