Looking for some best practices advice. Is there any way to correctly protect the backend method which i called from Auth0 hooks?
I have some backend logic to add custom claims and currently I am protecting my method with sort of long complex password. But I am looking into more correct approach like let’s say Twillio does with their ML web hooks or Facebook. When something special dynamic passed inside the request headers and after validated on the backend side.
If the endpoint makes use of HTTPS then by default the client part is already verifying the identity of the server and in such way has guarantees that is talking to a trusted party. This means that sending a high entropy API key/password on each request may already provide an acceptable level of security. The premise would be that with the HTTPS check the key/password would be protected from eavesdroppers.
Having said that you can indeed go beyond that; Facebook seems to apply what’s described in GitHub docs with an additional verification step to ensure that both parties are configured correctly. Given that you control both the client and server-side aspects of the communication that verification step from Facebook seems overkill so it might be better to just use the simplified version documented in the linked GH page. This approach would have the benefit that the shared secret would be setup by you in client and server separately and would never actually be sent during the communication phase.
In addition, you can also consider checking the source IP to have even more validation checks as the calls from hooks/rules would be coming from a set of IP addresses. In conclusion, depending on your security requirements an API key with HTTPS may prove sufficient, if not I would recommend the GH docs as they seem simpler and the Facebook verification step does not seem to add much when both parties (client and server) are controlled by the same entity.