在研究了各种webhook实现之后，我注意到他们使用的安全机制的趋势。
Visual Studio Team Services webhooks使用基本身份验证。
Microsoft Graph webhooks在每个webhook调用的正文中发送明文“clientState”。接收方根据已知值验证clientState。这类似于基本身份验证，因为每个请求都会通过网络发送明文凭证。
Slack传出webhook使用与Microsoft Graph非常相似的技术：在每个请求的正文中发送明文“令牌”。接收方根据已知值验证令牌。同样，与基本认证非常相似：每个请求都通过线路发送明文凭证。
在上述所有示例中，凭据永不过期。此外，每个钩子只有一个“令牌”值，这意味着如果令牌受到损害，则无法正常旋转令牌。
我对Basic Auth的理解是，它通常被避免，因为它要求客户端以明文形式存储凭证，这是一个安全风险。
继续前进，Github和Box webhooks使用共享机密和签名进行身份验证。
用于webhooks的安全机制与其各自API使用的安全机制形成对比 - 它们都使用OAuth 2.0和JWT承载令牌。
我还没有看到使用基于令牌的身份验证的webhook实现 - 例如，在Authorization标头中发送JWT承载令牌的平台。
我的问题是：webhook实现倾向于基础身份验证等安全性较低的机制是什么原因？他们为什么不直接使用OAuth 2.0和JWT，就像他们自己的API一样？
答案 0 :(得分：1)
基于令牌的身份验证系统并不意味着JWT是令牌格式。
如果您选择Slack或MS Graph实施，并使用clientState计划将token / Authorization从请求正文移至Bearer标题找不到重大差异。 确实，标头是传递用于验证请求的信息的最合适方式，服务器可能会以比请求主体更安全的方式处理标头...但是为此讨论让我们忽略它。
令牌将是by-reference token，其中实际值是无意义的，并且消费者从独立商店获得有效性和任何相关信息。在这种情况下，仅通过确保令牌与您期望的值匹配来判断有效性，并且没有与令牌相关联地存储的附加信息，但是这仍然是基于承载令牌的认证系统，在任何意义上都是让令牌可以发出请求。此外，令牌不是通过任何OAuth 2.0流程获得的，但对于像这样的场景来说，这样做会有点过分。
Github实现将被归类为对纯承载的改进，因为在线路上没有令牌，只有有效载荷的签名，这意味着能够解密通信信道的攻击者将只能重播捕获的请求，而不能发出具有不同有效负载的请求。
您可能无法使用功能齐全的OAuth 2.0和JWT作为令牌格式找到webhooks实现，因为这对于手头的用例来说是一种过度杀伤。
<强>更新：
JWT的到期时间是你想要的，因为它将是by-reference tokens（你称之为简单令牌）的到期。
我试图传递的信息是，您不需要JWT，也不需要OAuth，以获得基于令牌的身份验证系统。基于令牌的系统的安全特性可以独立于所使用的令牌格式来设计;是的，一些格式将简化某些方面，同时可能使其他方面更复杂。它始终是一种权衡......
在一个系统中，你只想确保谁是你信任的人，而不仅仅是一个完全陌生的人，JWT似乎有点过分;这当然是我的看法。
关于简单令牌本身就是秘密，取决于你秘密的意思。承载认证方案中使用的JWT或引用令牌如果泄露则会给出完全相同的结果。拥有令牌的人可以在令牌有效时发出请求。如果您指的是用于签署未在线路上传输的JWT的密钥/密钥，那么如果您使用签名的引用令牌，那么这将完全相同。
同样，对您的基本问题的诚实回答是，这些系统添加了他们认为值得考虑系统威胁模型的安全机制。就个人而言，我不同意不使用OAuth 2.0和JWT，因为在该用例中似乎完全不值得。我倾向于采用Github方法。
您可能不喜欢它们提供的安全特性，但MS Graph和Slack方法都是使用承载令牌的基于令牌的系统。