Verifying an HMAC (or other) webhook signature proves the payload came from the vendor. It does not prove which tenant, user, or resource that event is allowed to change in your system.
After the signature check, map the event to an internal subject and authorize the side effect—create invoice, revoke a seat, mark paid—against that object and tenant, with the same rules you use on your own APIs. A correctly signed body can still carry a spoofed tenant id or an action your customer never granted.
Network trust and crypto authenticity are not a policy. Decide subject + action + resource before you mutate state.
(Full disclosure, I work with Permit.io.) If you want authorization decisions kept out of ad-hoc webhook glue, Permit.io is one option.
Top comments (1)
This is a subtle but critical distinction. 🔐 Authentication answers “who sent this?”—authorization answers “are they allowed to do this?” Keeping those layers separate can prevent some serious security issues. Great insight! 👏