Description
A common (although less secure than HMAC) auth pattern that some webhook services uses to validate requests is a "shared secret". This is pretty much just an arbitrary string that both the client and the server have. The client sends a header that contains the shared secret (high-entropy string) and the server checks the header on the inbound request to ensure that it is valid. If it isn't the request is rejected.
As an example, here are the docs that Okta provides around their usage of shared secrets in webhook deliveries:
HTTP Headers
The header of requests sent by Okta appears as follows, provided that you configure the recommended authorization header and don't define additional custom headers:Accept: application/json
Content-Type: application/json
Authorization: {key}
The value sent in the Authorization header is a secret string that you provide to Okta when you register your event hook. This string serves as an API access key for your service, and Okta provides it in every request, allowing your code to check for its presence as a security measure. (This isn't an Okta authorization token, it's simply a text string you decide on.)Security
To secure the communication channel between Okta and your external service, use HTTPS for requests, and support is provided for header-based authentication. Okta recommends that you implement an authentication scheme using the authentication header, to be used to authenticate every request received by your external service.
This issue tracks work to implement a new lib/hooks/plugins/request_validator/shared_secret.rb request validator that extends the lib/hooks/plugins/request_validator/base.rb class.
This new "shared secret" request validator should be generic enough that it allows for each "endpoint config" to set what the SECRET_ENV_KEY should be and what header to look for in the request. A good example of a request validator that already does this today is the lib/hooks/plugins/request_validator/hmac.rb validator.