Setting up token validation for the Incoming Webhook trigger within Automation

[#1]

The Automation Incoming webhook trigger allows an automation rule to be triggered via a POST request. While the URL is unique, there are no additional authentication methods that are supported out of the box. The following feature request aims to address this:

• AUTO-182 - Support additional auth types for incoming and outgoing webhook components, e.g. to support GraphQL Actions, or NTLM auth

This article provides a workaround for additional security to the endpoint.

Warning

This method uses a random string (token) that can be passed along with the request payload and validated using a smart value condition. It is worth noting that this example uses a randomly generated string and is not considered to be cryptographically strong. The string is also stored in plaintext within the automation rule within the conditional check.

Setup

In this example the token is generated via the following command, however your token can be any string value:

openssl rand -base64 30

The token in this example will be:

zRhKm480uMvrdoEtG20bYg63wDE10UU/HRTTV2JT

Data sent as part of the request to the incoming webhook can be accessed via the {{webhookData}} smart value. If our token is sent using token as the key, this would be accessed via {{webhookData.token}}.

We can use this smart value to validate that the token is part of the payload that was sent:

If the token validation is successful, our audit log will display the value of the testData key in the payload, otherwise the audit logs will show that no actions were performed.

Testing the rule

The following cURL command can be used to test the payload, substituting the URL for your unique incoming webhook URL that the automation rule will generate:

curl -X POST -H 'Content-type: application/json' \
https://automation.atlassian.com/pro/hooks/509551bb11f2cfd6a4b12ea6644e145eef1 \
--data '{
  "token": "zRhKm480uMvrdoEtg20bYg63wDE10UU/HRTTV2JT",
  "testData": "Authentication was successful!"
}'

The above should result in a successful execution of the automation rule. I have included an example where the validation failed due to an incorrect token value being provided as well:

Caveat

Aside from the token being stored in plaintext within the automation rule, the script or third-party system sending the request to the incoming webhook URL has to be customizable in order to add the token to the payload.

You may need to work with your team or third-party vendor to explore how the payload can be expanded to add the token to.

Expanding the rule

An if/else block could be used with the conditional check to provide a clearer message in the audit logs if the token validation fails whether due to the token missing or being incorrect.

However this will return a successful execution on the automation logs instead of no actions performed, making it harder to flag within the audit logs.

The audit log entry for when the else block is triggered:

[Hala ElRoumy]

Cool! Thanks for sharing @Andras M_ !