在研究了各种webhook实现之后，我注意到它们使用的安全机制有一个趋势。
Visual Studio Team Services webhook使用Basic Authentication.
Microsoft Graph webhooks在每个webhook调用的主体中发送一个明文的"clientState"。接收方根据已知值验证clientState。这类似于基本身份验证，因为每个请求都通过网络发送明文凭据。
Slack外发webhook使用与Microsoft Graph非常相似的技术:在每个请求的主体中发送明文"令牌"。接收方根据已知值验证令牌。同样，这与基本身份验证非常相似:每个请求都通过网络发送明文凭据。
在上述所有示例中，凭据永远不会过期。此外，每个钩子只有一个"令牌"值，这意味着如果令牌被破坏，则无法优雅地旋转令牌。
我对Basic Auth的理解是，它通常是避免的，因为它要求客户端以明文形式存储凭据，这是一个安全风险。
继续，Github和Box webhooks使用共享密钥和签名进行身份验证。
webhook使用的安全机制与它们各自的API使用的安全机制相反——它们都使用OAuth 2.0和JWT承载令牌。
我还没有看到一个webhook实现使用基于令牌的身份验证——例如，在授权头中发送JWT承载令牌的平台。
我的问题是:webhook实现倾向于像基本身份验证这样不太安全的机制的原因是什么?为什么他们不直接使用OAuth 2.0和JWT，就像他们自己的API一样?
基于令牌的身份验证系统并不意味着将JWT作为令牌格式。
如果您选择Slack或MS Graph实现并使用Bearer方案将clientState/token从请求主体移动到Authorization标头，您将不会发现显着差异。这是真的，头将是最合适的方式来传递信息的设计，以验证请求和服务器可能处理头比请求体更安全的方式…
令牌将是一个引用令牌，其中实际值是无意义的，有效性和任何相关信息由消费者从一个独立的商店获得。在这种情况下，有效性纯粹是通过确保令牌与您期望的值匹配来判断的，并且没有存储与令牌相关的其他信息，但这仍然是一个基于承载令牌的身份验证系统，因为任何拥有令牌的人都可以发出请求。此外，这些令牌不是通过任何OAuth 2.0流获得的，但对于这些场景来说，这样做有些多余。
Github实现将被归类为对纯承载的改进，因为没有令牌在线路上传输，只有有效载荷的签名，这意味着能够解密通信通道的攻击者只能重放捕获的请求，而不能发出具有不同有效载荷的请求。
结论您可能找不到使用全功能的OAuth 2.0 + JWT作为令牌格式的webhook实现，因为对于手头的用例来说，这将是一种过度的使用。
:
JWT的过期是您想要的任何形式，就像引用令牌(您称之为简单令牌)的过期一样。
我试图传递的消息是，您不需要JWT或OAuth来拥有基于令牌的身份验证系统。基于令牌的系统的安全特性可以独立于所使用的令牌格式进行设计;是的，某些格式会简化某些方面，但可能会使其他方面更加复杂。这总是一种权衡…
在一个系统中，你只想确保打电话的人是你信任的人，而不仅仅是一个完全陌生的人，JWT似乎有点过头了;这当然是我的看法。
关于简单令牌本身是秘密，这取决于你对秘密的确切含义。如果在承载身份验证方案中使用JWT或按引用令牌泄露，则会得到完全相同的结果。任何拥有令牌的人都可以在令牌有效期间发出请求。如果您引用的是用于对未在网络上传输的JWT进行签名的秘密/密钥，那么如果您使用按引用签名的令牌，情况将完全相同。
再一次，对你的潜在问题的诚实回答是，这些系统添加了他们认为值得的安全机制，考虑到系统的威胁模型。就我个人而言，我并不反对不使用OAuth 2.0 + JWT，因为在这种情况下，它似乎完全不值得使用。我更倾向于使用Github方法。
你可能不喜欢它们提供的安全特性，但是MS Graph和Slack方法都是使用承载令牌的基于令牌的系统。